On Tue, Mar 02, 2010 at 11:10:52AM -0800, Bill Sommerfeld wrote: > On 03/02/10 08:13, Fredrich Maney wrote: > >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? > > While we're designing on the fly:
Heh. > Another possibility would be to use an > additional umask bit or two to influence the mode-bit - acl interaction. Well, I think the bit, if we must have one, belongs in the filesystem objects that have ACLs, as opposed to processes. There may be no umask to apply in remote access cases, so using a process attribute is likely to result in different behavior according to the access protocol and client. That might not be surprising for the CIFS case, but it certainly would be for the NFS case. But also I think it's the owner of an object that should decide what happens to the object's ACL on chmod rather than random programs and user environments. We might need multiple bits, but we do have multiple bits to play with in mode_t. The main issue with adding mode_t bits is going to be: will apps handle the appearance of new mode_t bits correctly? I suspect that they will, or at least that we'd condier it a bug if they didn't. Or we could add a new file attribute. But given cheap datasets, why not settle for a suitable dataset property as a starting point. I.e., maybe we could play with aclmode a little more. Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
