On Wed, 14 May 2025, Chuck Lever wrote: > On 5/14/25 7:43 AM, NeilBrown wrote: > > On Wed, 14 May 2025, Jeff Layton wrote: > >> On Wed, 2025-05-14 at 12:28 +1000, NeilBrown wrote: > > >> True. Anyone relying on this "protection" is fooling themselves though. > > > > As above: in some circumstances with physically secure networks > > (entirely in a locked room, or entire in a virtualisation host, or a > > VPN) it makes perfect sense. > > On a physically secure network where all the hosts are also known to be > secure, source port checking is wholly superfluous. It makes no sense > there. No, that is the only place that it makes sense. If you have a secure network of secure machines running a secure configuration of secure software managed by secure administrators, then you can trust that a low port number comes from secure software and, in particular, that the UID in the AUTH_SYS credential is reliable. If you don't have that security, then you cannot trust the port number or the uid and should not be accepting AUTH_SYS at all. If you *Do* have that security, then we can discuss if the "secure" or "insecure" flag is appropriate. If you know that all processes running on all nodes in the network are secure, and will only do what the admins let them do, then there is no need for "secure" with its restrictions, and "insecure" is perfectly fine. However if you allow lower-privileged processes - maybe you have a login server, or you let people upload their own cgi scripts to the web server - then "secure" is important to ensure users only access file that their uid has access to. > > > >>>> I don't see any really motivation for this change. Could you provide it > >>>> please? > >>> > >>> Or to put it another way: who benefits? > >>> > >> > >> Anyone running NFS clients behind NAT? > > > > Maybe that should have been in the commit message? > > Agreed, the commit message should have more beef (sorry, vegetarians). > > The commit message should also mention that NFS clients frequently > exhaust their privileged source port range, causing new mount > operations to fail sporadically. This is a well-documented problem > and the main reason we started moving Kerberized mounts to ephemeral > ports. > > Generally that's a situation that is sticky for a couple of minutes > while TCP sockets proceed through TIME_WAIT until the source port can > be re-used by another connection. > > > >> The main discussion came about when we were testing against a > >> hammerspace deployment. They were using knfsd as their DS's, and had > >> forgotten to add "insecure" to the export options. When the (NAT'ed) > >> client tried to talk to the DS's, it got back NFSERR3_PERM because of > >> this. It took a little while to ascertain the cause. > > > > "Change default to fix configuration problem"....??? > > The default must always be the more secure. "fail safe". > > Sure, but this option, although it's name is "secure", offers very > little real security. So we are actively promoting a mythological level > of security here, and that is a Bad Thing (tm). "very little" is not zero. "mythological" is unfair. There is real security is certain specific situations. NeilBrown
