NFS4 / ZFS: revert ACL to clean/inherited state

My problem is identical to this Windows question, but pertains NFS4 (Linux) and the underlying ZFS (OpenIndiana) we are using. We have this ZFS shared via NFS4 and CIFS for Linux and Windows users respectively. It would be nice for both user groups to benefit from ACLs, but the one missing puzzle piece goes thusly:

Each user has a home, where he sets a top-level, inherited ACL. He can later on refine permissions for the contained files/folders iteratively. Over time, sometimes permissions need to be generalized again to avoid increasing pollution of ACL entries. You can tweak the ACL of every single file if need be to obtain the wanted permissions, but that defeats the purpose of inherited ACLs. So, how can an ACL be completely cleared like in the question linked above?

I have found nothing about what a blank, inherited ACL should look like. This usecase simply does not seem to exist. In fact, the solaris chmod manpage clearly states

A-                            Removes all ACEs  for  current
                              ACL   on   file  and  replaces
                              current ACL with new ACL  that
                              represents  only  the  current
                              mode of the file.

I.e. we get three new ACL entries filled with stuff representing the permission bits, which is rather useless for cleaning up.

If I try to manually remove every ACE, on the last one I get

chmod A0- <file>
chmod: ERROR: Can't remove all ACL entries from a file

Which by the way makes me think: and why not? In fact, I really want the whole file-specific ACL gone.

The same holds for linux, which enumerates ACEs starting with 1(!), and verbalizes its woes less diligently

nfs4_setacl -x 1 <file>
Failed setxattr operation: Unknown error 524

So, what is the idea behind ACLs under Solaris/NFS? Can they never be cleaned up? Why does the recursion option for the ACL setting commands pollute all children instead of setting a single ACL and making the children inherit? Is this really the intention of the designers? I can clean up the ACLs using a windows client perfectly well, but am I supposed to tell the linux users they have to switch OS just to consolidate permissions?

Keiichi

Posted 2011-01-11T18:31:58.803

Reputation: 21

On the openindiana we use, chmod 0 <file> has the same effect as chmod A- <file>, i.e. it makes the file fall back to the bits permissions, which do not look quite fake to me as I can explicitly extract all three ACEs with a windows tool we wrote. /bin/chmod and /usr/bin/chmod seem to be the same. Am I still missing something? – Keiichi – 2011-01-17T17:55:39.560

"chmod 0" isn't equivalent to "chmod A-". The latter doesn't change the bits permissions, it just removes the existing ACLs. Despite possibly having the equivalent effect, ACLs and bit permissions aren't the same, i.e. aren't store at the same location, the reason why I wrote "fake". I guess you simply cannot remove the bits permissions, if this is what you are looking for, as they are inherently part of a POSIX file system. – jlliagre – 2011-01-17T21:26:07.427

Regardless of whether it is a fake ACL or not - the one file I treat with either A- or 0 does not inherit the ACL from its parent, which means there must still be something attached to it. This is very easy to verify since the parent directory has only 1 ACE (me). The file in question, however, always gives me 3 ACEs (me, group, everyone), no matter which chmod operation I use to try and get rid of the ACL. – Keiichi – 2011-01-18T11:49:10.947

NFS4 / ZFS: revert ACL to clean/inherited state

Answers