On Mon, 2025-05-19 at 16:02 +1000, 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? > > Here are some words that might be useful. I haven't tried to structure > them to fit well into the man page. Thanks Neil. I was planning to write up a manpage patch for this once the dust had settled from this discussion. I'll plan to incorporate something like what you've written below. > --------------- > sec=sys (also known as AUTH_SYS) is only safe to specify for clients > that are connected to the server by a secure network - either physically > secure such as in a locked room, or cryptographically secure such as > with a VPN where the client hardware is also secure (locked cage or > secure-boot etc). > > When such physical and/or crypto security is in place sec=sys can > safely be used and there is an extra configuration option available in > a choice between the "secure" and "insecure" export options. > > "insecure" means that all software running in the client node is fully > trusted to only access files on the NFS exports that it is expected to > access. In this case the server will accept connections from any TCP > port on the client (and messages from any UDP port) - as they can > equally be trusted. > > "secure" means that the clients are Unix-like systems and that only > "admin" software such as the kernel and administrative software running > as "root" can be trusted to access files appropriately. All other > software, which includes all user-space software running with a UID > other than zero, should be treated with caution and not given direct > access to the NFS server. In this case the server will reject > connections from TCP ports on the client with numbers not less than 1024 > (and UDP messages from ports not less than 1024) as such connections an > messages may be from an untrusted process. Note that on Unix-like > systems only privileged processes can send from ports below 1024. > > The "secure" option is enabled by default as it is least likely to give > away undesired access. Note that the names of the options do not > clearly match the descriptions given. > > ------------- > > 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? -- Jeff Layton <jlayton@xxxxxxxxxx>
