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

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.


> 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.


-- 
Chuck Lever