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. > One of the problems with setting a global umask on a user basis is > that it can be override very easily. If a user doesn't like the fact > that all files are group writeable he can easily change it and then he > usually forgets to set write-permissions manually when writing public > files. As a consequence other users who want to write that file come > to me to have the permissions reset as they can not even tell who is > the owner of the file and ask him. :-) > > >> Setting the umask to 002 is > >> not an option for us, but all files in the public area have to be > >> group writeable. Is there maybe a mount option to set the umask or a > >> server sided option which enforces the group writeable flag? > >> > >> I would expect that my use case is not that uncommon and that many > >> companys have the exact same problem. Would the inheritance work if we > >> used a fully NFS4-ACL compatible filesystem? > > > > No, and I suspect non-linux servers all have similar behavior in this > > respect. > > Unix servery yes, but on windows using NTFS you can inherit permissions. > > With PosixACLs Unix finally got permission inheritance too and this is > a blessing for administrators. The normal unix filesystem permissions > are good enough for many use cases but in a company with many users > and many different groups they do not fit. The simple case of allowing > users of two different groups access to a directory without giving > others rx access forces you to create a third group with all the users > of both groups. Adding new users gets a pain in the ass as you have to > add them to more and more groups just to get the permissions right. > > So Posix ACLs are really great for admins. From an admin's point of > view I can't understand why the NFS4-ACLs - which are actually > supperior to PosixACLs - still depend on the user's umask. I > understand the problems you have from a programmers point of view but > if I set a d:group:mask on a directory I expect that these permissions > get inherited on the client side, too - like it was with NFS3+ACL. > > Don't understand me wrong: I don't want to flame here - I appritiate > your work and I love NFS as it is damn fast. I just want to show you > what an admin's expectation is. People who use PosixACLs are used to > inheritance (if they set a default group or mask), windows people are > used to it anyway and nobody would expect that when using NFS4 it all > comes down to the user's umask settings. Especially as it was already > working with NFS3. I know that NFS3+ACL is a totally different topic > then NFS4+ACL but many user's won't care - especially as they do not > have any advantage from NFS4ACLs as they are mapped to PosixACLs > anyway. I appreciate the problem--if nothing else this is a subtle change that other admins will also hit, and that will be hard for them to diagnose. I just don't see a really good solution. > I really hate the security risks I have to take for NFS3 Are you aware that rpcsec_gss/krb5 still works for v3? There are a few holes left (sideband protocols, notably mount, still use auth_sys), but it might be enough for your purposes. > but in my > case I guess I have to revert the public shares back to NFS3. It would > be really great if you could think about implementing a umask > mount-option to allow enforced share based umask settings. > > > >> How do other people share public files with NFS4? If there is no other > >> way than setting the users's umask to 002, this would practically > >> limit the use of NFS4 to private shares like home directories. > > > > I don't understand why--can't you use the user-private-group trick?: > > - umask setting can be overriden easily - see above I'm surprised people fool with their umasks that much, but OK. > - we actually have directories where files should only be group readable. I don't get it--why not set an inheritable acl on those directories that permits only read to the group? --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
