| Message ID | 20201013110739.21922-1-sargun@sargun.me (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RFC] nfs: Use cred from fscontext during fsmount | expand |
diff --git a/fs/nfs/client.c b/fs/nfs/client.c index 4b8cc93913f7..bd26ec6a2984 100644 --- a/fs/nfs/client.c +++ b/fs/nfs/client.c @@ -985,7 +985,7 @@ struct nfs_server *nfs_create_server(struct fs_context *fc) if (!server) return ERR_PTR(-ENOMEM); - server->cred = get_cred(current_cred()); + server->cred = get_cred(fc->cred); error = -ENOMEM; fattr = nfs_alloc_fattr(); diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c index daacc78a3d48..818638cb10c4 100644 --- a/fs/nfs/nfs4client.c +++ b/fs/nfs/nfs4client.c @@ -1151,7 +1151,7 @@ struct nfs_server *nfs4_create_server(struct fs_context *fc) if (!server) return ERR_PTR(-ENOMEM); - server->cred = get_cred(current_cred()); + server->cred = get_cred(fc->cred); auth_probe = ctx->auth_info.flavor_len < 1;
This is a subtle change that is important for usage of NFS within user namespaces. With the new mount APIs, the fscontext has an associated struct cred. This struct cred is created at the time "fsopen" is called. This cred object contains user namespaces, network namespaces, etc... Right now, rather than using the cred / network namespace / user namespaces that are all acquired at the time fsopen is called, we use some bits at the time FSCONFIG_CMD_CREATE is called, and other bits at the time fsopen is called. Specifically, the RPC client itself lives in the network namespace that fsopen was called within. On the other hand, the credentials the RPC client uses are the ones retrieved at the time of FSCONFIG_CMD_CREATE. When FSCONFIG_CMD_CREATE is called, the vfs layer checks is the user has CAP_SYS_ADMIN in the init user ns, as NFS does not have the FS_USERNS_MOUNT flag enabled. Due to this, there is no way of configuring an NFS mount to use id mappings from a user namespace. It may make sense to switch from using clp->cl_rpcclient->cl_cred->user_ns as the user namespace for the idmapper to clp->cl_net->user_ns, to make sure that everything is aligned based on the net ns, and matches what has been previously discussed [1]. Although this is a change that would effect userspace, it is very unlikely that anyone is initializing the NFS FS FD in an unprivileged namespace, and then calling FSCONFIG_CMD_CREATE to only get the network namespace's effects, and not all of the effects. The fscontext API has provisions for being able to configure specific namespaces. [1]: https://lore.kernel.org/linux-nfs/CAMp4zn-mw1U3PoS9k_JePieU2+owg6hdXdrQ2Lt3p173J_sRbg@mail.gmail.com/ Signed-off-by: Sargun Dhillon <sargun@sargun.me> --- fs/nfs/client.c | 2 +- fs/nfs/nfs4client.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)