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

[Christopher Bii <christopherbii@hyub.org>]

Just want to weigh in on this briefly,

Firstly:

Yes, people have arbitrary access to low ports on their systems, but
such privileges are voided behind a NAT. Meaning a, possibly accidental,
publicly facing server may indeed benefit from such a check.

Secondly:

Even if NAT's didn't exist and you needed no system capabilities to bind
to any port. It is entirely legitimate for server/client applications,
let alone ones living in the kernel, to restrict client access based on
any criterion that may (de)legitimize them. Look at smtp. Yes there are
workarounds to everything, but goal isn't to stop bad actors in whole,
or even in large part. If such a thing can deter a small portion of
malicious traffic, it worked.

Thirdly:

Kinda goes with the above. Evaluating the efficiency of individual
components of a larger system can often lead to false conclusions.

Unless this has actively caused any issues for people where they would
rather it be opt-in, I think this should remain unchanged. If anything,
I'd say the argument to take it out completely is much more compelling.

It's a simple toggle option, those likely to need the change can easily
do so. If we assume zero user knowledge, they are likely incapable of
stepping outside the default ports used by client/server. Meaning, best
case scenario, the connection from port 60000 may be the vacuum cleaner.

Regards,
Christopher Bii

Jeff Layton wrote:
> On Wed, 2025-05-14 at 12:38 +1000, NeilBrown wrote:
>> On Tue, 13 May 2025, Jeff Layton wrote:
>>> Back in the 80's someone thought it was a good idea to carve out a set
>>> of ports that only privileged users could use. When NFS was originally
>>> conceived, Sun made its server require that clients use low ports.
>>> Since Linux was following suit with Sun in those days, exportfs has
>>> always defaulted to requiring connections from low ports.
>>>
>>> These days, anyone can be root on their laptop, so limiting connections
>>> to low source ports is of little value.
>>>
>>> Make the default be "insecure" when creating exports.
>>>
>>> Signed-off-by: Jeff Layton <jlayton@kernel.org>
>>> ---
>>> In discussion at the Bake-a-thon, we decided to just go for making
>>> "insecure" the default for all exports.
>>> ---
>>>   support/nfs/exports.c      | 7 +++++--
>>>   utils/exportfs/exports.man | 4 ++--
>>>   2 files changed, 7 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/support/nfs/exports.c b/support/nfs/exports.c
>>> index 21ec6486ba3d3945df0800972ba1dfd03bd65375..69f8ca8b5e2ed50b837ef287ca0685af3e70ed0b 100644
>>> --- a/support/nfs/exports.c
>>> +++ b/support/nfs/exports.c
>>> @@ -34,8 +34,11 @@
>>>   #include "reexport.h"
>>>   #include "nfsd_path.h"
>>>   
>>> -#define EXPORT_DEFAULT_FLAGS	\
>>> -  (NFSEXP_READONLY|NFSEXP_ROOTSQUASH|NFSEXP_GATHERED_WRITES|NFSEXP_NOSUBTREECHECK)
>>> +#define EXPORT_DEFAULT_FLAGS	(NFSEXP_READONLY |	\
>>> +				 NFSEXP_ROOTSQUASH |	\
>>> +				 NFSEXP_GATHERED_WRITES |\
>>> +				 NFSEXP_NOSUBTREECHECK | \
>>> +				 NFSEXP_INSECURE_PORT)
>>>   
>>>   struct flav_info flav_map[] = {
>>>   	{ "krb5",	RPC_AUTH_GSS_KRB5,	1},
>>> diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
>>> index 39dc30fb8290213990ca7a14b1b3971140b0d120..0b62bb3a82b0e74bc2a7eb84301c4ec97b14d003 100644
>>> --- a/utils/exportfs/exports.man
>>> +++ b/utils/exportfs/exports.man
>>> @@ -180,8 +180,8 @@ understands the following export options:
>>>   .TP
>>>   .IR secure
>>>   This option requires that requests not using gss originate on an
>>> -Internet port less than IPPORT_RESERVED (1024). This option is on by default.
>>> -To turn it off, specify
>>> +Internet port less than IPPORT_RESERVED (1024). This option is off by default
>>> +but can be explicitly disabled by specifying
>>>   .IR insecure .
>>
>> I think you mean "can be explicit enabled if desired" or similar.
>>
> 
> Yeah, it is a little awkward. I want to keep "insecure" in the manpage
> so that people know what the option is (and don't try to use something
> like "nosecure"). I'll see if I can rephrase that.
> 
>> If you really want to do this, you should require either "insecure" or
>> "secure" and generate a warning like we did when changing other defaults
>> in the past.  After a period of time you can remove that requirement.
>>
>> NeilBrown
>>
> 
> Requiring the option _would_ break existing setups, so I'd be against
> that plan.
> 
> One thing we could do is have exportfs log a warning to syslog when
> neither option is specified. Admins could specify it either way to
> silence the message. Would that overcome your objection?
> 
>>
>>>   (NOTE: older kernels (before upstream kernel version 4.17) enforced this
>>>   requirement on gss requests as well.)
>>>
>>> ---
>>> base-commit: 2cf015ea4312f37598efe9733fef3232ab67f784
>>> change-id: 20250513-master-89974087bb04
>>>
>>> Best regards,
>>> -- 
>>> Jeff Layton <jlayton@kernel.org>
>>>
>>>
>>>
>>
>