Re: [PATCH nfs-utils] exportfs: make "insecure" the default for all exports

[Chuck Lever <chuck.lever@oracle.com>]

On 5/19/25 2:02 AM, NeilBrown wrote:
> On Fri, 16 May 2025, Chuck Lever wrote:
>>
>> Fair enough. We'll focus on improving the man page text for now.
>>
> 
> Has anyone volunteered to do that?

Jeff has, but thank you for the text!


> I haven't added anything about mtls as I couldn't find out how nfsd
> interprets the identity presented in the client-side certificate.  If
> the identity is a "machine identity" then sec=sys would make sense on
> that connection.  If the identity is for a specific user and can map to
> a uid, the all_squash,anon=UID should be imposed on that connection.
> 
> Can you point me to any documentation about how the client certificate
> is interpreted by nfsd?

A TLS handshake is rejected if the server does not recognize the client
certificate's trust chain, as is standard practice for TLS with other
upper layer protocols. Therefore, when an export requires mtls, the
client must present a certificate and the server must recognize the
granting CA for that cert. In recent nfs-utils, there is a "Transport
layer security" section in exports(5) that might be updated to include
that information.

According to RFC 9289, client certificates are machine identities. To
identify a squash user, we plan to adopt the FreeBSD mechanism where
user squashing instructions can be included in the client certificate as
part of the Subject Alternate Name. This is not documented because it is
not yet implemented in Linux (but FreeBSD client and server do currently
implement this mechanism).


-- 
Chuck Lever