From: Sargun Dhillon <sargun@sargun.me>
To: "J . Bruce Fields" <bfields@fieldses.org>,
Chuck Lever <chuck.lever@oracle.com>,
Trond Myklebust <trond.myklebust@hammerspace.com>,
Anna Schumaker <anna.schumaker@netapp.com>,
David Howells <dhowells@redhat.com>,
Scott Mayhew <smayhew@redhat.com>
Cc: mauricio@kinvolk.io, Alban Crequy <alban.crequy@gmail.com>,
Sargun Dhillon <sargun@sargun.me>,
linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, Kyle Anderson <kylea@netflix.com>
Subject: [PATCH v5 2/2] NFSv4: Refactor to use user namespaces for nfs4idmap
Date: Thu, 12 Nov 2020 02:09:52 -0800 [thread overview]
Message-ID: <20201112100952.3514-3-sargun@sargun.me> (raw)
In-Reply-To: <20201112100952.3514-1-sargun@sargun.me>
In several patches work has been done to enable NFSv4 to use user
namespaces:
58002399da65: NFSv4: Convert the NFS client idmapper to use the container user namespace
3b7eb5e35d0f: NFS: When mounting, don't share filesystems between different user namespaces
Unfortunately, the userspace APIs were only such that the userspace facing
side of the filesystem (superblock s_user_ns) could be set to a non init
user namespace. This furthers the fs_context related refactoring, and
piggybacks on top of that logic, so the superblock user namespace, and the
NFS user namespace are the same.
Users can still use rpc.idmapd if they choose to, but there are complexities
with user namespaces and request-key that have yet to be addresssed.
Eventually, we will need to at least:
* Separate out the keyring cache by namespace
* Come up with an upcall mechanism that can be triggered inside of the container,
or safely triggered outside, with the requisite context to do the right
mapping. * Handle whatever refactoring needs to be done in net/sunrpc.
Signed-off-by: Sargun Dhillon <sargun@sargun.me>
Tested-by: Alban Crequy <alban.crequy@gmail.com>
---
fs/nfs/nfs4client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
index be7915c861ce..86acffe7335c 100644
--- a/fs/nfs/nfs4client.c
+++ b/fs/nfs/nfs4client.c
@@ -1153,7 +1153,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
next prev parent reply other threads:[~2020-11-12 10:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-12 10:09 [PATCH v5 0/2] NFS: Fix interaction between fs_context and user namespaces Sargun Dhillon
2020-11-12 10:09 ` [PATCH v5 1/2] NFS: NFSv2/NFSv3: Use cred from fs_context during mount Sargun Dhillon
2020-11-12 10:09 ` Sargun Dhillon [this message]
2020-11-19 15:39 ` [PATCH v5 2/2] NFSv4: Refactor to use user namespaces for nfs4idmap Christian Brauner
2020-11-13 18:46 ` [PATCH v5 0/2] NFS: Fix interaction between fs_context and user namespaces Sargun Dhillon
2020-11-24 18:42 ` Sargun Dhillon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201112100952.3514-3-sargun@sargun.me \
--to=sargun@sargun.me \
--cc=alban.crequy@gmail.com \
--cc=anna.schumaker@netapp.com \
--cc=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=dhowells@redhat.com \
--cc=kylea@netflix.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=mauricio@kinvolk.io \
--cc=smayhew@redhat.com \
--cc=trond.myklebust@hammerspace.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).