I haven't been really closely following this discussion, but I might have a solution.
A quick glance at 'man chmod(1)' will show that there is an unused bit in the file mask, namely '7000'. This has been there for quite a long time. I discovered it in '94 when a student accidentally set it on her home directory on HP-UX. Several hours of reading man pages later, I discovered a '-H' option to 'ls' which showed "hidden files". It seems that HP decided to use this unused bit to "hide" files and rewrote a few binaries (ls, chmod, etc..) to support it. Why not do the same sort of thing and use that extra bit to flag a file, or directory, as being an ACL only file and will negate the rest of the mask? That accomplishes what Paul is looking for, without breaking the existing model for those that need/wish to continue to use it? No mad proliferation of private primary groups or bizarre scripted workaround needed. fpsm On Tue, Mar 2, 2010 at 12:04 AM, Paul B. Henson <hen...@acm.org> 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. > >> 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 > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
