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.

> 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.

> 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?

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?

-- 
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

Reply via email to