[PATCH RFC 0/5] NFS: isolate mTLS client credentials by network namespace

An xprtsec=mtls mount names its client certificate and private key
by keyring serial, and tlshd reads those keys with its own
credentials. Each key therefore has to grant user read permission,
and any tlshd on the host that learns a serial can read it. Nothing
separates one network namespace's credentials from another's.

This series makes the network namespace the isolation domain. The
RFC thread asked whether the user or mount namespace is the better
binding. tlshd services the handshake socket of one network
namespace, so that is the namespace it already lives in.

  https://lore.kernel.org/linux-nfs/20260602154740.49861-1-cel@kernel.org/ (local)

The keyring is held in struct nfs_net rather than found by name,
because /proc/keys is not namespace scoped. Its serial travels with
each handshake instead (patches 3-4), and tlshd's possession of that
keyring is what lets a provisioned key grant no user read permission
at all. Both ends of the link exist today, in tls_handshake_accept()
and in tlshd. The handshake genetlink ABI and the cert_serial= and
privkey_serial= mount options do not change.

Still open is how userspace names the kernel-held keyring. Patch 5
prototypes a request_key type handled in the kernel and tagged
KEY_TYPE_NET_DOMAIN. A keyctl modeled on KEYCTL_GET_PERSISTENT, or a
read-only attribute on the netns-tagged nfs_client sysfs kobject,
would do the same job if the keyrings maintainers prefer one. Keys
that userspace adds are quota-charged by user namespace while the
keyring lives in nfs_net. Confirmation that this is sane when the
two boundaries differ would be welcome.

nfstlskey, the provisioning tool that consumes the key type, is
merged in https://github.com/oracle/ktls-utils/ .

Tested on one Fedora VM acting as both NFS client and NFSD, with
tlshd from ktls-utils 1.4.0: NFSv4.2 mounts with xprtsec=tls, with
xprtsec=mtls using the identity in tlshd.conf, and with xprtsec=mtls
using serials that nfstlskey provisioned.

---
Chuck Lever (5):
      NFS: name the init_nfs_fs() error labels
      NFS: allocate the .nfs keyring per network namespace
      SUNRPC: pass a keyring serial to the TLS handshake
      NFS: name the namespace .nfs keyring in the x509 handshake
      NFS: add a key type that reveals the namespace .nfs keyring serial

 Documentation/filesystems/nfs/index.rst   |   1 +
 Documentation/filesystems/nfs/keyring.rst |  67 ++++++++++
 fs/nfs/client.c                           |   9 +-
 fs/nfs/fs_context.c                       |   1 +
 fs/nfs/inode.c                            | 209 ++++++++++++++++++++++--------
 fs/nfs/netns.h                            |   9 ++
 fs/nfs/nfs3client.c                       |   1 +
 fs/nfs/nfs4client.c                       |   1 +
 include/linux/sunrpc/xprt.h               |   1 +
 net/sunrpc/xprtsock.c                     |   1 +
 10 files changed, 244 insertions(+), 56 deletions(-)
---
base-commit: df2908090cda368b01ff43709f51890076c56157
change-id: 20260917-nfs-mtls-identity-04c14f6f348d

Best regards,
--  
Chuck Lever [off-list ref]