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. 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... -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- 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
