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
