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

[Hannes Reinecke <hare@suse.de>]

On 9/18/26 7:21 PM, Benjamin Coddington wrote:
> On 18 Sep 2026, at 10:05, Chuck Lever wrote:
> 
>> 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/
>>
>> 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