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

On 9/18/26 7:21 PM, Benjamin Coddington wrote:

On 18 Sep 2026, at 10:05, Chuck Lever wrote:

quoted

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.

I think this is the old upcall/namespace problem that's never been generally
solved (as far as I know).  Here's a shameless plug to potentially revive
the original "key agent" concept which solves this in a general way.

The idea is - user space processes (tlshd) register themselves as key-agents
that can satisfy request-key.  A key agent represents itself as a key-type,
and the appropriate key agent is consulted for request-key if the calling
process has that agent's key in its keyrings.

Otherwise, this solution looks good - but without a general solution to this
problem, other folks building on keyrings will keep trying to solve this
problem.

Not sure. Basic problem with the 'upcall' mechanism is that it needs to
execute a userspace program by the time of the upcall.
And that (trivially) requires
a) a usable userspace to be present
and
b) the correct program to be be available

And that needs to happen at a time when the connection is _known_ to be
non-functional (otherwise you would not need to do an upcall).
So there's a likelyhood that this connection serves to userspace we are
about to access, and the whole thing stalls.

With tlshd we have the benefit that the daemon is always running, so
we don't have this issue.

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