On Tue, Sep 28, 2010 at 12:18:49PM -0700, Paul B. Henson wrote: > On Sat, 25 Sep 2010, [iso-8859-1] Ralph Böhme wrote: > > > Darwin ACL model is nice and slick, the new NFSv4 one in 147 is just > > braindead. chmod resulting in ACLs being discarded is a bizarre design > > decision. > > Agreed. What's the point of ACLs that disappear? Sun didn't want to fix > acl/chmod interaction, maybe one of the new OpenSolaris forks will do the > right thing...
I've researched this enough (mainly by reading most of the ~240 or so relevant zfs-discuss posts and several bug reports) to conclude the following: - ACLs derived from POSIX mode_t and/or POSIX Draft ACLs that result in DENY ACEs are enormously confusing to users. - ACLs derived from POSIX mode_t and/or POSIX Draft ACLs that result in DENY ACEs are susceptible to ACL re-ordering when modified from Windows clients -which insist on DENY ACEs first-, leading to much confusion. - This all gets more confusing when hand-crafted ZFS inherittable ACEs are mixed with chmod(2)s with the old aclmode=groupmask setting. The old aclmode=passthrough setting was dangerous and had to be removed, period. (Doing chmod(600) would not necessarily deny other users/groups access -- that's very, very broken.) That only leaves aclmode=discard and some variant of aclmode=groupmask that is less confusing. But here's the thing: the only time that groupmasking results in sensible ACLs is when it doesn't require DENY ACEs, which in turn is only when mode_t bits and/or POSIX ACLs are strictly non-increasing (e.g., 777, 775, 771, 750, 755, 751, etcetera, would all be OK, but 757 would not be). The problem then is this: if you have an aclmode setting that sometimes groupmasks and sometimes discards... that'll be confusing too! So one might wonder: can one determine user intent from the ACL prior to the change and the mode/POSIX ACL being set, and then edit the ZFS ACL in a way that approximates the user's intention? I believe that would be possible, but risky too, as the need to avoid DENY ACEs (see Windows issue) would often result in more permissive ACLs than the user actually intended. Taken altogether I believe that aclmode=discard is the simplest setting to explain and understand. Perhaps eventually a variant of groupmasking will be developed that is also simple to explain and understand, but right now I very much doubt it (and yes, I've tried myself). But much better than that would be if we just move to a ZFS ACL world (which, among other things, means we'll need a simple libc API for editing ACLs). Note, incidentally, that there's a groupmasking behavior left in ZFS at this time: on create of objects in directories with inherittable ACEs and with aclinherit=passthrough*. Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
