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@xxxxxxxxxxxx>: > > > > > >> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
