From: Bruce Fields <bfields@fieldses.org>
To: Chuck Lever <chucklever@gmail.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
libtirpc List <libtirpc-devel@lists.sourceforge.net>,
Guillem Jover <gjover@sipwise.com>
Subject: Re: [Libtirpc-devel] [PATCH] Do not bind to reserved ports registered in /etc/services
Date: Thu, 8 Mar 2018 16:35:18 -0500 [thread overview]
Message-ID: <20180308213518.GC16485@fieldses.org> (raw)
In-Reply-To: <7FFA3206-9E1D-49AE-A90F-0DFA7A68708F@gmail.com>
On Thu, Mar 08, 2018 at 04:28:53PM -0500, Chuck Lever wrote:
>
>
> > On Mar 8, 2018, at 4:26 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> >
> > On Thu, Mar 08, 2018 at 03:24:23PM -0500, bfields wrote:
> >> Looks like knfsd's not helpful here, though: the export option
> >> ("secure"/"insecure") defaults to "secure", which always requires a low
> >> port. It should be easy to modify "secure" to mean "require low ports
> >> only for auth_sys/auth_null", and that's probably the right thing to do.
> >
> > Disclaimer: totally untested.
> >
> > --b.
> >
> > commit ddc2a5f5ce98
> > Author: J. Bruce Fields <bfields@redhat.com>
> > Date: Thu Mar 8 15:49:48 2018 -0500
> >
> > nfsd: don't require low ports for gss requests
> >
> > In a traditional NFS deployment using auth_unix, the clients are trusted
> > to correctly report the credentials of their logged-in users. The
> > server assumes that only root on client machines is allowed to send
> > requests from low-numbered ports, so it can use the originating port
> > number to distinguish "real" NFS clients from NFS clients run by
> > ordinary users, to prevent ordinary users from spoofing credentials.
> >
> > The originating port number on a gss-authenticated request is less
> > important. The authentication ties the request to a user, and we take
> > it as proof that that user authorized the request. The low port number
> > check no longer adds much.
> >
> > So, don't enforce low port numbers in the auth_gss case.
> >
> > Signed-off-by: J. Bruce Fields <bfields@redhat.com>
>
> Looks plausible to me, and I like the approach.
>
> Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
Thanks for taking a look. Also thinking something like this for
exports(5):
--b.
commit 4e3583326c19
Author: J. Bruce Fields <bfields@redhat.com>
Date: Thu Mar 8 16:32:11 2018 -0500
exports: document change to "insecure" export option
We're changing the kernel to allow gss requests from high ports even
when "secure" is set.
If the change gets backported to distro kernels, the kernel version may
be an imperfect predictor of the behavior, but I think it's the best we
can do. I consider the change a bugfix, so hopefully this is OK.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
index db47dfdee775..1596fd75578b 100644
--- a/utils/exportfs/exports.man
+++ b/utils/exportfs/exports.man
@@ -131,10 +131,12 @@ this way are ro, rw, no_root_squash, root_squash, and all_squash.
understands the following export options:
.TP
.IR secure
-This option requires that requests originate on an Internet port less
-than IPPORT_RESERVED (1024). This option is on by default. To turn it
-off, specify
+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
.IR insecure .
+(NOTE: older kernels (before upstream kernel version 4.17) enforced this
+requirement on gss requests as well.)
.TP
.IR rw
Allow both read and write requests on this NFS volume. The
next prev parent reply other threads:[~2018-03-08 21:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-10 0:49 [PATCH] Do not bind to reserved ports registered in /etc/services Guillem Jover
2018-01-11 15:18 ` Steve Dickson
2018-01-12 18:41 ` Guillem Jover
2018-01-12 19:12 ` [Libtirpc-devel] " Thorsten Kukuk
2018-01-12 19:19 ` Tom Talpey
2018-02-08 18:07 ` Chuck Lever
2018-02-08 18:36 ` Chuck Lever
2018-03-06 18:09 ` Chuck Lever
2018-03-08 20:24 ` J. Bruce Fields
2018-03-08 21:26 ` J. Bruce Fields
2018-03-08 21:28 ` [Libtirpc-devel] " Chuck Lever
2018-03-08 21:35 ` Bruce Fields [this message]
2018-01-11 15:50 ` Chuck Lever
2018-01-12 18:05 ` Guillem Jover
2018-01-12 19:12 ` Chuck Lever
2018-01-12 21:12 ` [Libtirpc-devel] " Thorsten Kukuk
2018-01-12 21:14 ` Chuck Lever
2018-01-12 21:30 ` Matt Benjamin
2018-01-12 22:08 ` Steve Dickson
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=20180308213518.GC16485@fieldses.org \
--to=bfields@fieldses.org \
--cc=chucklever@gmail.com \
--cc=gjover@sipwise.com \
--cc=libtirpc-devel@lists.sourceforge.net \
--cc=linux-nfs@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).