linux-kernel - [RFC PATCH] nfs: Use cred from fscontext during fsmount

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:   Tue, 13 Oct 2020 04:07:39 -0700
From:   Sargun Dhillon <sargun@...gun.me>
To:     "J . Bruce Fields" <bfields@...ldses.org>,
        Chuck Lever <chuck.lever@...cle.com>,
        Trond Myklebust <trond.myklebust@...merspace.com>,
        Anna Schumaker <anna.schumaker@...app.com>
Cc:     Sargun Dhillon <sargun@...gun.me>, linux-nfs@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [RFC PATCH] nfs: Use cred from fscontext during fsmount

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@...gun.me>
---
 fs/nfs/client.c     | 2 +-
 fs/nfs/nfs4client.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

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;

-- 
2.25.1