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

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?

>
>
>> I might be okay to have it tagged per net-namespace, though, as all
>> current users are in some shape or form being network related.
>> But I'm not sure if that stays that way, so I am worried if we're
>> not restricting ourselves to much by that choice.
>> As really, the question is: what is the driving the namespace selection?
>> Is it the _requesting_ layer, ie the layer issuing the mount() call?
>> Or is it the _providing_ layer, ie the layer providing the
>> devices/interfaces where the mount() call is operating on?
>> If it's the former, then we need to tag is as
>> net-namespace. If it's the latter, then we need to tag it as a
>> user-namespace / mount-ns.
> tlshd is a network layer service, so it doesn't make sense to bind
> it to a user or mount namespace, IMHO.

I agree with network namespace isolation.