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

[Chuck Lever <chuck.lever@oracle.com>]

On 6/5/25 12:48 PM, Trond Myklebust wrote:
> On Wed, 2025-06-04 at 15:53 -0400, Steve Dickson wrote:
>>
>>
>> On 6/4/25 3:17 PM, Jeff Layton wrote:
>>> On Wed, 2025-06-04 at 14:26 -0400, Steve Dickson wrote:
>>>> Hello all,
>>>>
>>>> On 5/13/25 9:50 AM, 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..69f8ca8b5e2ed50b837ef
>>>>> 287ca0685af3e70ed0b 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|NFSEX
>>>>> P_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..0b62bb3a82b0e74bc2a7e
>>>>> b84301c4ec97b14d003 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 .
>>>>>    (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,
>>>> My apologies but I got a bit lost in the fairly large thread
>>>> What as is consensus on this patch? Thumbs up or down.
>>>> Will there be a V2?
>>>>
>>>> I'm wondering what type documentation impact this would
>>>> have on all docs out there that say one has to be root
>>>> to do the mount.
>>>>
>>>> I guess I'm not against the patch but as Neil pointed
>>>> out making things insecure is a different direction
>>>> that the rest of the world is going.
>>>>
>>>> my two cents,
>>>>
>>>>
>>>
>>> Thumbs down for now. Neil argued for a more measured approach to
>>> changing this.
>>>
>>> I started work on a manpage patch for exports(5) but it's not quite
>>> ready yet. I also want to look at converting some manpages to
>>> asciidoc
>>> as we go, to make future updates easier.
>> Sounds like a plan... Thanks!
>>
>> steved.
>>
>>
> 
> Can we please add an explanation to the manpage to let people know why
> this default is set?

That's exactly what Jeff is working on right now.


> It is basically in order to prevent any untrusted Tom, Dick or Harry
> from spinning up a userspace NFS client that spoofs a different user.
> 
> IOW: The assumption is that you should at least be able to trust the
> kernel NFS client to at provide the correct credential for an untrusted
> user.
> If you can't make that assumption, then your server should probably be
> configured to squash any AUTH_SYS credential supplied by this client.


-- 
Chuck Lever