On Mon, May 19, 2025 at 7:16 AM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@xxxxxxxxxxx. > > > 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. Do you also have some configurable settings for if/how the DNS field in the client's X.509 cert is checked? The range is, imho: - Don't check it at all, so the client can have any IP/DNS name (a mobile device). The least secure, but still pretty good, since the ert. verified. - DNS matches a wildcard like *.umich.edu for the reverse DNS name for the client's IP host address. - DNS matches exactly what reverse DNS gets for the client's IP host address. Wildcards are discouraged by some RFC, but are still supported by OpenSSL. rick > > 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 >
