Paul B. Henson wrote: > On Fri, 14 Mar 2008, Mark Shellenbaum wrote: > >> 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. > > Ah, I was interpreting them from the standpoint of an NFSv4 ACL, not from a > legacy POSIX perspective. > >>> 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. > > What was fixed? That the ACL would no longer be considered trivial?
No longer considered trivial. > >> 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. > > Hmm... What's the point of having the ability to inherit ACL entries if you > can't actually control the permissions on new files and directories that > will be created? Inheriting ACEs works better if you don't use owner@, group@ or [EMAIL PROTECTED] Those ACEs affect the mode of the file > >>> 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. > > Ok, if I understand you correctly, they are split such that you can modify > the ACL pertaining to the actual directory object without modifying the ACL > that will be inherited by future child objects? That makes sense. > >>> 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. > > Am I mistaken or confused in my thought that such a mode would be highly > desirable? I would like to be able to configure permissions, particularly > inherited permissions, such that they would be fully defined by the ACL, > and not modified in unknown ways by whatever umask happened to be in effect > when the file or directory was created. I would also like to be able to > maintain ACLs via either UNIX commands or from a CIFs client and have them > stay compatible. I think it is a misnomer to call the current > implementation of ZFS a "pure ACL" system, as clearly the ACLs are heavily > contaminated by legacy mode bits. > Feel free to open an RFE. It may be a tough sell with PSARC, but maybe if we have enough customer requests maybe they can be won over. > Thanks for the response... > > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
