Hi, in nfs-discuss, Andrwe Watkins has brought up the question, why an inheritable ACE is split into two ACEs when a descendant directory is created. Ref: http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/zfs/zfs_acl.c#1506 I must admit that I had observed this behavior many times, but never asked myself why ACE inheritance is implemented like this. The best explanation I can come up with is that chmod calls on the mode bits should not change inheritable ACEs, and splitting inheritable (non inherit-only) ACEs is an easy way to achieve this. Does this interpretation match the original intention, or are there any other or better reasons? It there a reason why inheritable ACEs are split always, even if the particular chmod call would not require splitting them? Thank you, Nils
Hi, I just noticed that Mark Shellenbaum has replied to the same question in a thread "ACL not being inherited correctly" on zfs-discuss. Sorry for the noise. Out of curiosity, I would still be interested in answers to this question: It there a reason why inheritable ACEs are split always, even if the particular chmod call would not require splitting them? For instance, a mode bit change would never influence NON- at owner/@group/@everyone ACEs and even for the @owner/@group/@everyone, one could check if the mode bits are actually changed by the chmod call. Does this make any sense? Thank you, Nils
Nils Goroll wrote:> Hi, > > I just noticed that Mark Shellenbaum has replied to the same question in > a thread "ACL not being inherited correctly" on zfs-discuss. > > Sorry for the noise. > > Out of curiosity, I would still be interested in answers to this question: > > It there a reason why inheritable ACEs are split always, even if the > particular chmod call would not require splitting them? > > For instance, a mode bit change would never influence > NON- at owner/@group/@everyone ACEs and even for the > @owner/@group/@everyone, one could check if the mode bits are actually > changed by the chmod call.Any group entry could have its permissions modified in some situations (i.e. group has greater permissions than owner). Its true that a user entry wouldn''t necessarily need it, but in order to keep the algorithm simpler we just always do the split. It would be simple enough to exclude user entries from splitting. Feel free to open a bug on this.> > Does this make any sense? > > Thank you, > > Nils > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Mark and all, thank you for your reply and your explanations. I don''t want to just open a yet another bug before having a rough idea about how the code should be improved. I''ll see if I find some time to prepare a suggestion (this might never happen). At any rate, simplicity is always a good argument. Nils