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@xxxxxxxxxx>
> > > > ---
> > > > 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@xxxxxxxxxxxxxxx
