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

["Chuck Lever" <cel@kernel.org>]

On Sun, Sep 13, 2026, at 12:05 PM, Chuck Lever wrote:
> On Tue, Jun 2, 2026, at 11:47 AM, Chuck Lever wrote:
>
>> Userspace front end
>> ===================
>>
>> With the keyring in place the front end is straightforward and follows
>> the nvme-cli / cifscreds pattern.
>>
>> A new nfs-utils tool -- working name nfstlskey, fitting the nfsidmap /
>> nfsconf family -- manages x.509 client identities:
>>
>>     nfstlskey add  <identity> --cert cert.pem --key key.pem
>>     nfstlskey list
>>     nfstlskey remove <identity>
>>
>> The add subcommand reads the PEM cert and key, converts each to DER,
>> and creates two "user" keys on the netns .nfs keyring ("user" because
>> tlshd consumes raw DER via keyctl_read_alloc()), with possessor-only
>> read. Description convention:
>>
>>     nfs:x509:<identity>:cert
>>     nfs:x509:<identity>:privkey
>>
>> The mount command names the identity:
>>
>>     mount -o xprtsec=mtls,tls_identity=<identity> server:/export /mnt
>>
>> mount.nfs runs in the caller's namespace, searches the .nfs keyring for
>> the two descriptions, and passes the existing cert_serial= and
>> privkey_serial= options to the kernel. tls_identity= is purely a
>> userspace convenience that resolves a name to the serials the kernel
>> already accepts; the raw serial options remain as a documented escape
>> hatch. Both get documented in nfs(5), with a new nfstlskey(8) page.
>>
>> tlshd changes are minimal: confirm the per-handshake link of the passed
>> keyring happens before the cert and privkey serials are read, and
>> retire the now-unnecessary .nfs entry in the keyrings= startup path.
>
> I've created an nfstlskey tool and pushed it to the nfs-mtls-identity
> branch of https://github.com/oracle/ktls-utils/ . It compiles, but I
> haven't otherwise tested it. There is a nfstlskey(8) man page.
>
> There is a change to tlshd so that the handshake children processes
> pick up the .nfs keyring instead of picking .nfs up at tlshd start-up
> time. This avoids the ordering problem of starting tlshd before the
> NFS client module is loaded.
>
> I'm hoping this new tool can be used with current kernels, though
> all of this is missing proper namespace support at the moment, so
> it should work in the init net-ns only. Kernel patches for namespace
> support are in the works.
>
> Please kick the tires. Is this the kind of administrative UX you
> expect?

Top five patches in

https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git/log/?h=nfs-mtls-identity

provide the kernel plumbing to copy key serial numbers provided by
NFS mount options to the tlshd upcall.


-- 
Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)