Inheriting group write permission, but not execute for files, on OmniOS (Illumos) using ZFS ACL

Question

We operate with umask 027 most of the time. For certain directories, where multiple users are involved, I found a cool way to emulate umask 002 using ACL inheritance.

Here's the command I'm using. Essentially this is chmod 775 with inheritance:

/usr/bin/chmod A=owner@:rwxpDaARWcCos:fd:allow,group@:rwxpDaARWcs:fd:allow,everyone@:rxaRcs:fd:allow $@`

$@ represents the list of files to be updated. I'm using the OpenSolaris edition in /usr/bin/chmod, since /usr/gnu/bin/chmod doesn't appear to support full ACL syntax.

Works like a charm, and also sets g+s so the group name is inherited. However, there are a couple improvements I would like help with:

1. The a+x (execute) permission should only apply to directories, and should not be inherited for files automatically.
2. The o+r (read) permission should only apply to files, and not directories, because I want to disable ls ability for the anonymous users.

I'm very pleased with OmniOS/Illumos & ZFS, but unfortunately it uses the Solaris ACL scheme which is quite different from the more commonly found Linux ACL syntax.

Some kind of conditional inheritance is in order, inheriting one way for files, and the other way for directories. Is this possible?

Answer 1

The a+x (execute) permission should only apply to directories, and should not be inherited for files automatically.

You can specify for each ACE (access control entry) of the ACL (the complete list) how it should be inherited. The options are, taken from the Solaris admin guide, which also applies to OmniOS (Tables 8.1 to 8.3):

• file_inherit (f): Only inherit the ACL from the parent directory to the directory's files.
• dir_inherit (d): Only inherit the ACL from the parent directory to the directory's subdirectories.
• inherit_only (i): Inherit the ACL from the parent directory but applies only to newly created files or subdirectories and not the directory itself. Requires f/d/fd.
• no_propagate (n): Only inherit the ACL from the parent directory to the first-level contents of the directory, not the second-level or subsequent contents. Requires f/d/fd.

You can add multiple ACEs for the same user and achieve the desired effect, because they are combined when applying (similar to Windows ACLs). Example reduced to @owner, because for the others it would be the same:

/usr/bin/chmod A=\
    owner@:rw-p-D-ARWcCos:fd-----:allow, \
    owner@:--x---a-------:-d-----:allow, \
    [...]
$@

This means that

• the first ACE is applied to the directory andis inherited for all files and directories, but excludes a+x permissions
• the second ACE is applied to the directory and is inherited for all subdirectories, but not for files and only has the a+x permissions
• to get the resulting complete ACL, you can "overlay" both lines for directories (this is why I prefer the syntax with the dashes, you see what is missing)

I have not tested that it does what you want, it sometimes depends on applications too, so you should test it. Inherited files and directory ACLs are marked with a large I at the last position, like owner@:rw-p-D-ARWcCos:fd----I:allow.

The o+r (read) permission should only apply to files, and not directories, because I want to disable ls ability for the anonymous users.

Similar to the first question, but the other way round. You can also combine it with n if you just want first-level inheritance (similar to find -maxdepth 1). Again, take care to test because most likely the simple flags are not enough and you also need the advanced ones (ARWC). Also, you still can apply ACLs recursively with option chmod -R on files and directories, which may be needed in some cases (for example if ACLs should be retroactively modified, because once a file is written, its ACL is fixed, depending on the property of aclinherit).

---

I'm very pleased with OmniOS/Illumos & ZFS, but unfortunately it uses the Solaris ACL scheme which is quite different from the more commonly found Linux ACL syntax.

This may look unfortunate from your side now, but the ACLs closely model the NFSv4 ACLs, so you will not need to change anything if you decide to use NFS version 4. It also closely represents the Windows ACLs (only exception: order on SOlaris is fixed, order on Windows is always Deny before Allow, but if you do not use Deny it does not matter), which means you can edit the permissions from each Windows PC that has the Co rights set to allowed. This works for domains and workgroups, so interoperability with Windows is better than the workarounds Samba has employed in the past.