On Wed, Dec 10, 2014 at 1:31 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > We've gotten complaints that the effect of NFSv4 ACL inheritance is > often overridden by common umask settings. > > Options: > > - Do nothing, make sure the behavior's documented. I don't > think this will make people happy, but I haven't tried to > figure out exactly what any of them are trying to do. POSIX documents exactly how open(O_CREATE) works. I'd say that if anything, we'd need to document how inherited ACLs are supposed to work in this situation. > > - Do as in NFSv3 and teach the client to skip the umask in the > case the parent directory has inheritable ACEs. The following > patch is a proof-of-concept with some bugs. It requires > documenting what we mean by "parent directory has interitable > ACEs"--I'm taking it to mean that the ACL has some ACE with > inheritance bits set, as that's simple to explain. Drawbacks > include: requires fetching and caching an ACL on create; > there's a race between checking and creating; creates may fail > just because reading the ACL fails. Yeah, this is a non-starter. > - New protocol: e.g. add a new attribute representing the > un-umasked mode, send both that and the regular mode on > create, let the server sort it out. > > - Something else??: adopt some convention that uses redundant > information in a compound (multiple SETATTRs?) to communicate > umask to "in the know" servers without changing behavior on > existing servers. Provide an "ignore the umask" mount option. > Maybe I'm missing a clever trick. > > Any ideas? As I indicated above, I'd like to see a little more debate around how we expect this whole ACL inheritance thing to work in practice. The NFSv4 spec is all about enabling Windows-like ACL behaviour, but that isn't necessarily the right thing for Linux applications. IOW: before we discuss fixes, I'd like to understand how the current behaviour is broken. -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- 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
