Linux NFS development
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@hammerspace.com>
To: "jlayton@kernel.org" <jlayton@kernel.org>,
	"steved@redhat.com" <steved@redhat.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"loghyr@gmail.com" <loghyr@gmail.com>
Subject: Re: [PATCH nfs-utils] exportfs: make "insecure" the default for all exports
Date: Thu, 5 Jun 2025 16:48:05 +0000	[thread overview]
Message-ID: <c65a34cba5884a0d20fe3a9c9247919e2602fd40.camel@hammerspace.com> (raw)
In-Reply-To: <e6dbb6be-4e58-4d94-8912-05a5eee87ada@redhat.com>

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?

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.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com

  reply	other threads:[~2025-06-05 16:48 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-13 13:50 [PATCH nfs-utils] exportfs: make "insecure" the default for all exports Jeff Layton
2025-05-13 14:17 ` Chuck Lever
2025-05-13 15:14 ` Lionel Cons
2025-05-13 15:35   ` Jeff Layton
2025-05-13 16:11   ` Chuck Lever
2025-06-04 17:12     ` Cedric Blancher
2025-06-04 18:20       ` Chuck Lever
2025-05-14  2:16 ` NeilBrown
2025-05-14  2:28   ` NeilBrown
2025-05-14 11:17     ` Jeff Layton
2025-05-14 11:43       ` NeilBrown
2025-05-14 12:02         ` Jeff Layton
2025-05-14 21:58           ` NeilBrown
2025-05-14 12:56         ` Chuck Lever
2025-05-14 21:47           ` NeilBrown
2025-05-15 12:01             ` Chuck Lever
2025-05-15 21:44               ` NeilBrown
2025-05-16 12:09                 ` Chuck Lever
2025-05-19  6:02                   ` NeilBrown
2025-05-19 11:39                     ` Jeff Layton
2025-05-19 14:16                     ` Chuck Lever
     [not found]                       ` <4bee9565-c2a8-4b90-be57-7d1340fa9ed7@esat.kuleuven.be>
2025-05-19 20:51                         ` Chuck Lever
2025-05-20  1:44                       ` Rick Macklem
2025-05-20 13:20                         ` Chuck Lever
2025-05-25 17:29                           ` Chuck Lever
2025-05-26  0:09                             ` NeilBrown
2025-05-26  1:47                               ` Rick Macklem
2025-05-26  1:52                                 ` Rick Macklem
2025-05-26  2:29                                 ` NeilBrown
2025-05-28  0:57                                   ` Rick Macklem
2025-05-27 13:28                                 ` Chuck Lever
2025-05-27 15:05                               ` Chuck Lever
2025-05-27 15:58                                 ` Rick Macklem
2025-05-27 16:29                                 ` Rick Macklem
2025-05-27 16:58                                   ` Chuck Lever
2025-05-28  1:06                                     ` Rick Macklem
2025-05-27 19:18                                 ` Benjamin Coddington
2025-05-27 19:41                                   ` Chuck Lever
2025-05-27 20:25                                     ` Benjamin Coddington
2025-05-28 14:07                                       ` Chuck Lever
2025-05-28  1:24                                     ` NeilBrown
2025-05-28  2:48                                       ` Rick Macklem
2025-05-14 11:46     ` Chuck Lever
2025-05-14 12:28   ` Thomas Haynes
2025-05-14 21:49     ` NeilBrown
2025-05-14  2:38 ` NeilBrown
2025-05-14 11:20   ` Jeff Layton
2025-05-15  1:32     ` Christopher Bii
2025-05-21  9:06 ` Sebastian Feld
2025-05-21 12:25   ` Jeff Layton
2025-05-21 13:14   ` Chuck Lever
2025-05-21 13:43     ` Chuck Lever
2025-06-04 17:07 ` Cedric Blancher
2025-06-04 18:26 ` Steve Dickson
2025-06-04 18:45   ` Cedric Blancher
2025-06-04 19:17   ` Jeff Layton
2025-06-04 19:53     ` Steve Dickson
2025-06-05 16:48       ` Trond Myklebust [this message]
2025-06-05 18:09         ` Chuck Lever
2025-06-05  8:20     ` Cedric Blancher
2025-06-05 13:54       ` Chuck Lever

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c65a34cba5884a0d20fe3a9c9247919e2602fd40.camel@hammerspace.com \
    --to=trondmy@hammerspace.com \
    --cc=jlayton@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=loghyr@gmail.com \
    --cc=steved@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox