On Mon, Mar 01, 2010 at 09:04:58PM -0800, Paul B. Henson wrote: > On Mon, 1 Mar 2010, Nicolas Williams wrote: > > Yes, that sounds useful. (Group modebits could be applied to all ACEs > > that are neither owner@ nor everyone@ ACEs.) > > That sounds an awful lot like the POSIX mask_obj, which was the bane of my > previous filesystem, DFS, and which, as it seems history repeats itself, I > was also unable to get an option implemented to ignore it and allow ACL's > to work without impediment.
Alternatively group modebits apply to only the group@ ACEs. This could be just yet another option. If no modebits were to apply to ACEs with subjects other than owner@/group@/everyone@ (what about subjects that match the file's owner/group but aren't owner@/gr...@?) then there'd be no way to use modebits as a big filter for ACLs. This is why I proposed the above. > > If users have private primary groups then you can have them run with > > umask 007 or 002 and use set-gid and/or inherittable ACLs to ensure that > > users can share files in specific directories. (This is one reason that > > I recommend always giving users their own private primary groups.) > > The only reason for the recommendation to give users their own private > primary groups is because of the lack of flexibility of the umask/mode bits > security model. In an environment with inheritable ACL's (that aren't > subject to being violated by that legacy security model) there's no real > need. All reasons I have for it really come back to this: the idea of a primary group and file group is an anachronism from back when ACLs (and supplementary group memberships!) were overkill. Think back to the days when the AT&T labs were the only place where Unix ran and Unix had a user base in the tens of users. We're stuck with the notion of a primary group (Windows seems to have it for interop with POSIX). The way to make the best of that situation is to give every user their own private group. > > Alternatively we could have a new mode bit to indicate that the group > > bits of umask are to be treated as zero, or maybe assign this behavior > > to the set-gid bit on ZFS. > > So rather than a nice simple option granting ACL's immunity from umask/mode > bits baggage, another attempted mapping/interaction? You have a good idea of what is "simple" for your use case. Your use case also appears to be greatly influenced by what we could (should, do) consider to be a bug in Samba. Your idea of "simple" may not match every one else's. And your idea of "simple" might well differ if that one application didn't use chmod() at all. Personally I don't see a simple, non-surprising solution. I see a set of solutions that one could pick from. In all cases I think we need a way to synthesize modebits from ACLs (e.g., for objects created via protocols that have no conception of modebits but have a conception of ACLs) -- that's a difficult problem because any algorithm for doing that will necessarily be lossy in many cases. > If you only ever access ZFS via CIFS from windows clients, you can have a > pure ACL model. Why should access via local shell or NFSv4 be a poor > stepchild and chained down with legacy semantics that make it exceedingly > difficult to actually use ACL's for their intended purpose? I am certainly not advocating that. Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
