From: Hannes Reinecke <hare@suse.de>
To: Chuck Lever <cel@kernel.org>,
Trond Myklebust <trondmy@kernel.org>,
Anna Schumaker <anna@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
Christian Brauner <brauner@kernel.org>,
David Howells <dhowells@redhat.com>,
Sagi Grimberg <sagi@grimberg.me>
Cc: linux-nfs@vger.kernel.org, keyrings@vger.kernel.org,
kernel-tls-handshake@lists.linux.dev, netdev@vger.kernel.org,
linux-doc@vger.kernel.org
Subject: Re: [PATCH RFC 2/5] NFS: allocate the .nfs keyring per network namespace
Date: Fri, 18 Sep 2026 16:44:50 +0200 [thread overview]
Message-ID: <bbc4ff6f-aa38-4862-96fe-518c3b4df4d6@suse.de> (raw)
In-Reply-To: <20260918-nfs-mtls-identity-v1-2-197e568d78a7@kernel.org>
On 9/18/26 4:05 PM, Chuck Lever wrote:
> Commit 87268f7a4f1f ("nfs: create a kernel keyring") allocates one
> .nfs keyring at module load, and nothing in the NFS client reads it.
> One module-wide keyring also cannot isolate x.509 credentials
> between network namespaces. Each tlshd instance services the
> handshake socket of one network namespace, so a credential
> provisioned for that namespace's mounts has to be reachable by that
> tlshd and by no other.
>
> Allocate one .nfs keyring per network namespace in nfs_net_init()
> and release it in nfs_net_exit(). tlshd finds a keyring by name
> through /proc/keys, which is not namespace scoped, so each handshake
> request has to carry the keyring serial instead. Allocate the
> keyring under a kernel credential rather than that of the task
> creating the namespace, so an LSM labels every namespace's keyring
> the same way.
>
> Signed-off-by: Chuck Lever <cel@kernel.org>
> ---
> fs/nfs/inode.c | 81 +++++++++++++++++++++++++++++++---------------------------
> fs/nfs/netns.h | 2 ++
> 2 files changed, 46 insertions(+), 37 deletions(-)
>
> diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
> index 832923be43a9..bd327fbb12d8 100644
> --- a/fs/nfs/inode.c
> +++ b/fs/nfs/inode.c
> @@ -2641,11 +2641,50 @@ static int nfsiod_start(void)
> unsigned int nfs_net_id;
> EXPORT_SYMBOL_GPL(nfs_net_id);
>
> +#ifdef CONFIG_KEYS
> +static int nfs_init_keyring(struct nfs_net *nn)
> +{
> + struct cred *cred;
> + struct key *keyring;
> +
> + cred = prepare_kernel_cred(&init_task);
> + if (!cred)
> + return -ENOMEM;
> + keyring = keyring_alloc(".nfs", GLOBAL_ROOT_UID, GLOBAL_ROOT_GID, cred,
> + (KEY_POS_ALL & ~KEY_POS_SETATTR) |
> + (KEY_USR_ALL & ~KEY_USR_SETATTR),
> + KEY_ALLOC_NOT_IN_QUOTA, NULL, NULL);
> + put_cred(cred);
> + if (IS_ERR(keyring))
> + return PTR_ERR(keyring);
> + nn->nfs_keyring = keyring;
> + return 0;
> +}
> +
> +static void nfs_exit_keyring(struct nfs_net *nn)
> +{
> + key_put(nn->nfs_keyring);
> +}
> +#else
> +static inline int nfs_init_keyring(struct nfs_net *nn)
> +{
> + return 0;
> +}
> +
> +static inline void nfs_exit_keyring(struct nfs_net *nn)
> +{
> +}
> +#endif /* CONFIG_KEYS */
> +
> static int nfs_net_init(struct net *net)
> {
> struct nfs_net *nn = net_generic(net, nfs_net_id);
> int err;
>
> + err = nfs_init_keyring(nn);
> + if (err)
> + return err;
> +
> nfs_clients_init(net);
>
> if (!rpc_proc_register(net, &nn->rpcstats)) {
> @@ -2663,14 +2702,18 @@ static int nfs_net_init(struct net *net)
> rpc_proc_unregister(net, "nfs");
> err_proc_rpc:
> nfs_clients_exit(net);
> + nfs_exit_keyring(nn);
> return err;
> }
>
> static void nfs_net_exit(struct net *net)
> {
> + struct nfs_net *nn = net_generic(net, nfs_net_id);
> +
> rpc_proc_unregister(net, "nfs");
> nfs_fs_proc_net_exit(net);
> nfs_clients_exit(net);
> + nfs_exit_keyring(nn);
> }
>
> static struct pernet_operations nfs_net_ops = {
> @@ -2680,35 +2723,6 @@ static struct pernet_operations nfs_net_ops = {
> .size = sizeof(struct nfs_net),
> };
>
> -#ifdef CONFIG_KEYS
> -static struct key *nfs_keyring;
> -
> -static int __init nfs_init_keyring(void)
> -{
> - nfs_keyring = keyring_alloc(".nfs",
> - GLOBAL_ROOT_UID, GLOBAL_ROOT_GID,
> - current_cred(),
> - (KEY_POS_ALL & ~KEY_POS_SETATTR) |
> - (KEY_USR_ALL & ~KEY_USR_SETATTR),
> - KEY_ALLOC_NOT_IN_QUOTA, NULL, NULL);
> - return PTR_ERR_OR_ZERO(nfs_keyring);
> -}
> -
> -static void nfs_exit_keyring(void)
> -{
> - key_put(nfs_keyring);
> -}
> -#else
> -static inline int nfs_init_keyring(void)
> -{
> - return 0;
> -}
> -
> -static inline void nfs_exit_keyring(void)
> -{
> -}
> -#endif /* CONFIG_KEYS */
> -
> /*
> * Initialize NFS
> */
> @@ -2716,13 +2730,9 @@ static int __init init_nfs_fs(void)
> {
> int err;
>
> - err = nfs_init_keyring();
> - if (err)
> - return err;
> -
> err = nfs_sysfs_init();
> if (err < 0)
> - goto err_keyring;
> + return err;
>
> err = register_pernet_subsys(&nfs_net_ops);
> if (err < 0)
> @@ -2779,8 +2789,6 @@ static int __init init_nfs_fs(void)
> unregister_pernet_subsys(&nfs_net_ops);
> err_sysfs:
> nfs_sysfs_exit();
> -err_keyring:
> - nfs_exit_keyring();
> return err;
> }
>
> @@ -2796,7 +2804,6 @@ static void __exit exit_nfs_fs(void)
> nfs_fs_proc_exit();
> nfsiod_stop();
> nfs_sysfs_exit();
> - nfs_exit_keyring();
> }
>
> /* Not quite true; I just maintain it */
> diff --git a/fs/nfs/netns.h b/fs/nfs/netns.h
> index 36658579100d..da0854510404 100644
> --- a/fs/nfs/netns.h
> +++ b/fs/nfs/netns.h
> @@ -16,6 +16,7 @@ struct bl_dev_msg {
> uint32_t major, minor;
> };
>
> +struct key;
> struct nfs_netns_client;
>
> struct nfs_net {
> @@ -36,6 +37,7 @@ struct nfs_net {
> #endif /* CONFIG_NFS_V4 */
> struct nfs_netns_client *nfs_client;
> spinlock_t nfs_client_lock;
> + struct key *nfs_keyring;
> ktime_t boot_time;
> struct rpc_stat rpcstats;
> #ifdef CONFIG_PROC_FS
>
Curiously enough, I had been pondering a similar issue.
Thing is, when running within a container (eg a docker one) access
access to /proc/keys might be restricted, and from what I've
gathered each container gets its own, _empty_ keyring.
(certainly an empty session keyring ...).
So I wonder what'll happen with the predefined keyrings (like the
.nvme keyring); one possibility is surely to make them network
namespace aware.
But the alternative approach I'm exploring is to allow each container
to create its own (.nvme) keyring; that would have the advantage of
being more flexible and we wouldn't need to rely on 'magic' names.
Hmm?
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
next prev parent reply other threads:[~2026-09-18 14:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 14:05 [PATCH RFC 0/5] NFS: isolate mTLS client credentials by network namespace Chuck Lever
2026-09-18 14:05 ` [PATCH RFC 1/5] NFS: name the init_nfs_fs() error labels Chuck Lever
2026-09-18 14:05 ` [PATCH RFC 2/5] NFS: allocate the .nfs keyring per network namespace Chuck Lever
2026-09-18 14:44 ` Hannes Reinecke [this message]
2026-09-18 15:15 ` Chuck Lever
2026-09-19 16:22 ` Chuck Lever
2026-09-18 14:05 ` [PATCH RFC 3/5] SUNRPC: pass a keyring serial to the TLS handshake Chuck Lever
2026-09-18 14:05 ` [PATCH RFC 4/5] NFS: name the namespace .nfs keyring in the x509 handshake Chuck Lever
2026-09-18 14:05 ` [PATCH RFC 5/5] NFS: add a key type that reveals the namespace .nfs keyring serial Chuck Lever
2026-09-18 18:00 ` Randy Dunlap
2026-09-19 15:59 ` Chuck Lever
2026-09-18 17:21 ` [PATCH RFC 0/5] NFS: isolate mTLS client credentials by network namespace Benjamin Coddington
2026-09-19 15:46 ` Chuck Lever
2026-09-21 8:45 ` Hannes Reinecke
2026-09-21 11:17 ` Benjamin Coddington
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=bbc4ff6f-aa38-4862-96fe-518c3b4df4d6@suse.de \
--to=hare@suse.de \
--cc=anna@kernel.org \
--cc=brauner@kernel.org \
--cc=cel@kernel.org \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kernel-tls-handshake@lists.linux.dev \
--cc=keyrings@vger.kernel.org \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rdunlap@infradead.org \
--cc=sagi@grimberg.me \
--cc=skhan@linuxfoundation.org \
--cc=trondmy@kernel.org \
/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