On Fri, Feb 26, 2010 at 02:50:05PM -0800, Paul B. Henson wrote: > 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 ;).
I believe we can do a bit better. A chmod that adds (see below) or removes one of r, w or x for owner is a simple ACL edit (the bit may turn into multiple ACE bits, but whatever) modifying / replacing / adding owner@ ACEs (if there is one). A similar chmod that affecting group bits should probably apply to group@ ACEs. A similar chmod that affecting other should apply to any everyone@ ACEs. For set-uid/gid and the sticky bits being set/cleared on non-directories chmod should not affect the ACL at all. For directories the sticky and setgid bits may require editing the inherittable ACEs of the ACL. > 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, chmod(2) always takes an absolute mode. ZFS would have to reconstruct the relative change based on the previous mode... but how to know what the "previous mode" was? ZFS would have to construct one from the owner@/group@/everyone@ + set-uid/gid + sticky bits, if any. Best effort will do. > 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. You should probably stop using the set-gid bit on directories and use inherttable ACLs instead... Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
