diff options
| author | Chuck Lever <cel@kernel.org> | 2026-10-06 11:31:13 -0400 |
|---|---|---|
| committer | Anna Schumaker <anna.schumaker@hammerspace.com> | 2026-10-12 16:28:07 -0400 |
| commit | d8884f64c93d1b96b3c7f596c8c41c5e5e3e832a (patch) | |
| tree | 2d0c03fb5eec55b72c74e5de9eda3f1a9a7aa683 /tools/lib/python | |
| parent | 69fe71a4ddae3cda8ffcb858ec94a948fe109f69 (diff) | |
| download | linux-next-d8884f64c93d1b96b3c7f596c8c41c5e5e3e832a.tar.gz linux-next-d8884f64c93d1b96b3c7f596c8c41c5e5e3e832a.zip | |
NFS: allocate the .nfs keyring per network namespace
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 but not by a tlshd in another user namespace.
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 number 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.
The keyring grants its owner every permission and everyone else
none. Make the owner of the network namespace's user namespace the
keyring's owner, so that in a container with its own user namespace
the container's root can provision the keyring and its tlshd can
link it.
Signed-off-by: Chuck Lever <cel@kernel.org>
Signed-off-by: Anna Schumaker <anna.schumaker@hammerspace.com>
Diffstat (limited to 'tools/lib/python')
0 files changed, 0 insertions, 0 deletions
