When the server is serving a mixed set of clients where some support the
NFS 4.2 umask attribute and some don't, we need to make sure to reset the
nfd thread umask to 0 when serving a client that isn't providing the umask,
otherwise a stale umask from a previous request will be applied.
This was only done in the nfsd4_decode_open() callsite, but not in
nfsd4_decode_create() leading to newly created directories ending up with
wrong permissions in some cases. To avoid any such inconsistency in the
future, reset the umask in nfsd4_decode_fattr() where we know if the
client did provide a umask.
Fixes: 47057abde515 (nfsd: add support for the umask attribute)
Signed-off-by: Lucas Stach <l.stach@xxxxxxxxxxxxxx>
---
fs/nfsd/nfs4xdr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/nfsd/nfs4xdr.c b/fs/nfsd/nfs4xdr.c
index e502fd16246b..1eb33b34c51b 100644
--- a/fs/nfsd/nfs4xdr.c
+++ b/fs/nfsd/nfs4xdr.c
@@ -486,6 +486,8 @@ nfsd4_decode_fattr(struct nfsd4_compoundargs *argp, u32 *bmval,
dummy32 = be32_to_cpup(p++);
*umask = dummy32 & S_IRWXUGO;
iattr->ia_valid |= ATTR_MODE;
+ } else if (umask) {
+ *umask = 0;
}
if (len != expected_len)
goto xdr_error;
@@ -927,7 +929,6 @@ nfsd4_decode_open(struct nfsd4_compoundargs *argp, struct nfsd4_open *open)
case NFS4_OPEN_NOCREATE:
break;
case NFS4_OPEN_CREATE:
- current->fs->umask = 0;
READ_BUF(4);
open->op_createmode = be32_to_cpup(p++);
switch (open->op_createmode) {
--
2.16.1
--
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
