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. The only objection I could see also applies to the current posix code: there's a small race allowing the file create to be done with stale information from the parent directory. > The existing 'noacl' mount option could then turn off this type of check > in cases where the administrator doesn't care to follow inheritance > rules... OK. For now this falls into the category of patches I'd happily shepherd along if someone else would write them. Shouldn't be too hard to write though. --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
