Re: [RFC] NFS: named client identities for mTLS mounts and a per-namespace .nfs keyring

On 6/5/26 2:32 PM, Sagi Grimberg wrote:
> 
> 
> On 03/06/2026 17:27, Chuck Lever wrote:
>> On Tue, Jun 2, 2026, at 6:39 PM, Hannes Reinecke wrote:
>>> I am all for making keyrings namespace-aware. Logically I _think_ they
>>> should be tagged per user-namespace, as this really is about the
>>> filesystem (and as such would warrant to be tagged per mount ns).
>>> Tagging it per net-namespace is not a great fit (well, for me, at
>>> least), as also block devices might require keys to present the
>>> bdev (eg nvme authentication)
>> My understanding of the proposal is that there is one keyring on the
>> system for .nfs and the keys in it are visible only in the namespace
>> where they were created.
>>
>> Therefore the consumer (say, NFS, or NFSD) is running in a particular
>> network namespace. It will create keys on the one .nfs keyring, but
>> only the tlshd in that same network namespace will have access to
>> those keys.
> 
> Can tlshd run in multiple network namesapces today?

AIUI the netlink upcall in the kernel wants to use a netlink socket in
the current network namespace. So there has to be at least one tlshd
instance in each network namespace that wants to use in-kernel TLS
consumers.


-- 
Chuck Lever