> 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:
I've researched this by reading the specs for NFSv4, withdrawn draft POSIX 1e and Darwin ACLs, and implemented mapping between them in an UNIX AFP fileserver. > - 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. Imo the approach of intertwinig UNIX mode with ACEs was a bad idea in the first place, but it's in the spec so of course the implemenatations that follow it must honour it. POSIX 1e do something similar, but my point being here is, that this is not neccessarily the most clever, clean and safe spec. Note that Darwin (OS X) does _not_ do this mumbo-jumbo, so ... > - 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.) ... in Darwin this will not remove any ACL from the object. The Darwin kernel evaluates permissions in a first match paradigm, evaluating the ACL before the mode and it does not intertwine ACL and mode. It's a slick, clean, easy to understand and safe design. With this model I can stick a ACL to an oject saying "deny unredeemed_hacker everything" and be sure that this ACL will stick there without being removed by any chmod. Fixing one NFSv4 spec ACL design issue by (mapping mode and ACL) by just removing ACLs when the mapping must be done is spec conforming, but imo a bad idea. I haven't yet really studied the details of this implementation change in 147, so maybe I'm complaining to early. Regards, -r -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
