Re: NFS4 ACL <-> Posix ACL

["J. Bruce Fields" <bfields@fieldses.org>]

On Tue, Mar 24, 2009 at 06:28:06PM -0400, Trond Myklebust wrote:
> On Tue, 2009-03-24 at 18:21 -0400, J. Bruce Fields wrote:
> > On Tue, Mar 24, 2009 at 05:44:07PM -0400, Trond Myklebust wrote:
> > > On Tue, 2009-03-24 at 16:10 -0400, J. Bruce Fields wrote:
> > > > On Tue, Mar 24, 2009 at 02:56:25AM +0100, Alex Bremer wrote:
> > > > > 2009/3/23, J. Bruce Fields <bfields@fieldses.org>:
> > > > > >> So is there any way to make newly created files group writeable except
> > > > > >> for setting the umask of each user to 002?
> > > > > >
> > > > > > I think that's the only option.
> > > > > >
> > > > > > And that looks hard to fix; if we were going to implement the same
> > > > > > "inheritance overrides umask" exception as we do for posix acls, either:
> > > > > >
> > > > > > 	- The server would have to know about the umask; this would
> > > > > > 	  require a protocol change.  (But it might not be that hard;
> > > > > > 	  you could have a write-only "set the mode to this, but only in
> > > > > > 	  the absence of inheritance" attribute.)
> > > > > > 	- The client would have to do the inheritance itself, as it does
> > > > > > 	  with posix acls.  This is perhaps not impossible, but it's
> > > > > > 	  much more complicated with v4 acls.
> > > > > >
> > > > > > Hm.  Another odd option: do the open with the create mode + umask, as we
> > > > > > currently do, then do a subsequent setattr to the create mode if the
> > > > > > create mode is more generous and if the client detects inheritable acls
> > > > > > on the parent directory.
> > > > > 
> > > > > Why so complicated? Of course these options would be the nicest way to
> > > > > do it as it allows to set different permission inheritances on each
> > > > > directory. However for many use cases it would be enough if one could
> > > > > set the permissions on a share basis. A simple umask mount-option
> > > > > would already help a lot. This way administrators could enforce a
> > > > > umask on a share.
> > > > 
> > > > I don't know what to think of a umask mount option.  That's a question
> > > > for Trond.
> > > 
> > > Ugh, no. We already have too many mount options, and this suggestion
> > > doesn't even fix any problems.
> > > 
> > > The correct thing to do is to check for acl support on the server, and
> > > then check directories for inheritance aces before we decide to create a
> > > file.
> > 
> > OK, so if we find an inheritable ace on the file, then we just skip
> > sending the umask in the mode that's sent on open.

Sorry, I meant "the inheritable ace on the parent directory" in the
above.

> No. That would violate the spec. I meant that the client needs to check
> if the server supports acls, and then needs to check those acls on the
> directory in which it wants to create the file.
> 
> In order to avoid any races, it probably needs to send the inherited ACL
> in the createattrs field. Otherwise, if a user were to remove the
> inherited ACL before the client sends the OPEN/CREATE, then the server
> would no longer have an ACL to set on the file...

Either that, or send the umask-less mode and let the server do the
inheritance calculation.

--b.