Paul B. Henson wrote: > On Fri, 14 Mar 2008, Mark Shellenbaum wrote: > >> this behavior is only possible from a Windows client. When creating >> files from unix the POSIX rules apply and the requestors mode must be >> honored, which results in the owner@, group@, and everyone@ entries >> always being set on the files ACL. > > It's one thing to feature POSIX compatibility; it's another to force it. I > was hoping with a pure ACL implementation to be able to disregard the > legacy POSIX mode bits baggage and have ACLs handled sanely. It doesn't > look like I can achieve that though :(. > > Upon creation, a brand-new ZFS file system has the following ACL: > > drwxr-xr-x 2 root sys 2 Mar 14 14:42 . > owner@:--------------:------:deny > owner@:rwxp---A-W-Co-:------:allow > group@:-w-p----------:------:deny > group@:r-x-----------:------:allow > everyone@:-w-p---A-W-Co-:------:deny > everyone@:r-x---a-R-c--s:------:allow > > > Given that in my understanding any permission not explicitly allowed is > denied by default, what is the purpose of the explicitly listed deny > components? They in no way alter the effective permissions, and result in a > Windows client accessing the permissions via samba issuing an error > regarding the ordering. >
That is not correct. The deny entries are necessary for POSIX semantics. In POSIX are only allowed to pick up permissions from the owner, group or other class. You can't pick up part of the permissions you are looking for from the group class and then some more from the other class. > The creation of a file in the file system results in the following ACL: > > > -rw-r--r-- 1 root root 0 Mar 14 14:43 foo > owner@:--x-----------:------:deny > owner@:rw-p---A-W-Co-:------:allow > group@:-wxp----------:------:deny > group@:r-------------:------:allow > everyone@:-wxp---A-W-Co-:------:deny > everyone@:r-----a-R-c--s:------:allow > > Again, it seems the deny components are extraneous, serving only to > complicate the ACL. So, I modified the ACL to look as follows, resulting in > the exact same effective permissions, but much simpler to parse: > > > -rw-r--r-- 1 root root 0 Mar 14 14:43 foo > owner@:rw-p---A-W-Co-:------:allow > group@:r-------------:------:allow > everyone@:r-----a-R-c--s:------:allow > > Note that the above file still has a "trivial" ACL, as indicated by the > lack of "+" in the permission bits. > That is actually a bug that was recently fixed. > Now, let's say I wanted to remove group and other readability from that > file via "chmod og-r foo" -- that results in: > > -rw-------+ 1 root root 0 Mar 14 14:43 foo > owner@:-------A-W-Co-:------:allow > group@:--------------:------:allow > everyone@:------a-R-c--s:------:allow > owner@:--x-----------:------:deny > owner@:rw-p---A-W-Co-:------:allow > group@:rwxp----------:------:deny > group@:--------------:------:allow > everyone@:rwxp---A-W-Co-:------:deny > everyone@:------a-R-c--s:------:allow > > WTF? Now there are three entries each for owner, group and everyone. Three > unnecessary deny ACE's have been added, two of the owner allow entries > overlap, there is a group allow ACE permitting nothing. And oddly, a file > that started with a "trivial" ACL, and was modified via mode bit changes, > suddenly has a nontrivial ACL. That just seems broken... > > Moving on to inherited permissions, lets say I wanted to create a directory > writable by the group, with newly created files and subdirectories also > writable by the group. I thought the following ACL should allow that: > > drwxrwxr-x+ 2 root root 2 Mar 14 14:46 groupw > everyone@:--------------:f-i---:allow > group@:rw------------:f-i---:allow > owner@:rw------------:f-i---:allow > owner@:rwxp---A-W-Co-:-d----:allow > group@:rwxp----------:-d----:allow > everyone@:r-x---a-R-c--s:-d----:allow > > Creating a new file in that directory results in: > > > -rw-r--r--+ 1 root root 0 Mar 14 14:53 groupw/file > everyone@:--------------:------:allow > group@:--------------:------:allow > owner@:--------------:------:allow > owner@:--x-----------:------:deny > owner@:rw-p---A-W-Co-:------:allow > group@:-wxp----------:------:deny > group@:r-------------:------:allow > everyone@:-wxp---A-W-Co-:------:deny > everyone@:r-----a-R-c--s:------:allow > Thats because the requesters mode must be honored. You can't disregard the mode the application requests and the ACL needs to be altered to match the mode. That why the three entries are basically nulled out, but the ACEs are left in place in case you want to change them later. > What is this? There are three unnecessary deny entries, the group did not > get write ability, and everyone has readability even though that was not > intended. I see this behavior even after changing aclinherit to > passthrough. > > My umask was 022 for the previous test, I changed it to 000 for this: > > -rw-rw-rw-+ 1 root root 0 Mar 14 14:53 groupw/file2 > everyone@:--------------:------:allow > group@:--------------:------:allow > owner@:--------------:------:allow > owner@:--x-----------:------:deny > owner@:rw-p---A-W-Co-:------:allow > group@:--x-----------:------:deny > group@:rw-p----------:------:allow > everyone@:--x----A-W-Co-:------:deny > everyone@:rw-p--a-R-c--s:------:allow > > Now, group does have write permissions as was intended, but so does > everyone. > > Restoring my umask, I created a directory: > > drwxrwxr-x+ 2 root root 2 Mar 14 14:55 groupw/dir > everyone@:--------------:f-i---:allow > group@:rw------------:f-i---:allow > owner@:rw------------:f-i---:allow > owner@:rwxp---A-W-Co-:-di---:allow > owner@:-------A-W----:------:allow > group@:rwxp----------:-di---:allow > group@:--------------:------:allow > everyone@:--------------:-di---:allow > everyone@:--------------:------:allow > owner@:--------------:------:deny > owner@:rwxp---A-W-Co-:------:allow > group@:-w-p----------:------:deny > group@:r-x-----------:------:allow > everyone@:-w-p---A-W-Co-:------:deny > everyone@:r-x---a-R-c--s:------:allow > > > Why did my ACE's that were applicable to the parent directory and marked > inheritable be split into two separate ACE's, one inherit only and one > applicable? That seems redundant and overly complicates the ACL. > That necessary for effective propagation of ACEs. That way the ACE is propagated down as it was set at the first place the ACE was set. > > On the other hand, let's say I wanted to create a directory which would > have no privileges available to the group for new stuff inside of it: > > > drwx------+ 2 root root 2 Mar 14 14:46 groupnw > everyone@:--------------:f-i---:allow > group@:--------------:f-i---:allow > owner@:rw------------:f-i---:allow > owner@:rwxp---A-W-Co-:-d----:allow > group@:--------------:-d----:allow > everyone@:--------------:-d----:allow > > A new file with default umask 022: > > > -rw-r--r--+ 1 root root 0 Mar 14 14:54 groupnw/file > everyone@:--------------:------:allow > group@:--------------:------:allow > owner@:--------------:------:allow > owner@:--x-----------:------:deny > owner@:rw-p---A-W-Co-:------:allow > group@:-wxp----------:------:deny > group@:r-------------:------:allow > everyone@:-wxp---A-W-Co-:------:deny > everyone@:r-----a-R-c--s:------:allow > > Group and everyone readability that was not wanted. > > And with umask 000: > > -rw-rw-rw-+ 1 root root 0 Mar 14 14:55 groupnw/file2 > everyone@:--------------:------:allow > group@:--------------:------:allow > owner@:--------------:------:allow > owner@:--x-----------:------:deny > owner@:rw-p---A-W-Co-:------:allow > group@:--x-----------:------:deny > group@:rw-p----------:------:allow > everyone@:--x----A-W-Co-:------:deny > everyone@:rw-p--a-R-c--s:------:allow > > Group and everyone readability and writability. > > What I would really like to see is a mode that completely ignores > umask/mode bits and simply applies the inherited ACL with no modification > or complication. I don't see any way to do that? > No such mode exists. > To achieve directories in which files are created with my desired > permissions, it seems I would need to construct a horribly complicated ACL > with a bunch of deny's to override the automatically created allows? > > I am very sad; we have been searching for ages for a filesystem to deploy > that would allow simultaneous access via NFSv4 and CIFS, with equivalent > permissions from both sides, equivalent access from both sides, and the > ability to change permissions are either side and have them make sense on > the other. I thought ZFS with NFSv4 native ACL support was going to it -- > but so far the ACL implementation makes no sense to me. > > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
