On Fri, 26 Feb 2010, Bill Sommerfeld wrote: > I believe this proposal is sound.
Mere words can not express the sheer joy with which I receive this opinion from an @sun.com address ;). > There are already per-filesystem tunables for ZFS which allow the system > to escape the confines of POSIX (noatime, for one); I don't see why a > "chmod doesn't truncate acls" option couldn't join it so long as it was > off by default and left off while conformance tests were run. It always frustrates me when cutting edge technology is artificially hampered by the chains and straitjacket of an obsolete (or at least not necessarily relevant to the problem at hand) standard. I had the same problem with our previous DCE/DFS environment and the POSIX mask_obj. Compliance with standards is good, but also having the option to knowingly disregard them is even better :). There are (as always) various pesky details that need to be ironed out. For example, it should probably only apply to objects with a non-trivial ACL; ones with a trivial ACL should still be chmod'able for compatibility. There's also the question of what to do with the non-access-control pieces of the legacy mode bits that have no ACL equivilent (suid, sgid, sticky bit, et al). I think the only way to set those is with an absolute chmod, so there'd be no way to manipulate them in the current implementation without whacking the ACL. That's likely done relatively infrequently, those bits could always be set before the ACL is applied. In our current deployment the only one we use is sgid on directories, which is inherited, not directly applied. I was hoping to find some ZFS engineers that might be interested in tossing the concept back and forth to the point where it was workable, but so far no luck. It looks like you work more in the network security area? Ignoring the zfs specific details, from an abstract security perspective, it seems generally "not good" to be able to so easily and unintentionally subvert explicitly configured security policy :(. I've got an open case, SR#72456444, regarding chmod/ACL conflicts, if anybody would like to help it along :). Thanks... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
