There were 2 things wrong with auth flavour ordering:
- Mountd used to advertise AUTH_NULL as the first flavour on
the list, which means that it prefers AUTH_NULL to anything
else (as per RFC 2623 section 2.7).
- Mount.nfs used to scan the returned list in reverse order,
and stopping at the first AUTH_NULL or AUTH_SYS encountered.
If a server advertises (AUTH_SYS, AUTH_NULL), it will by
default choose AUTH_NULL and have degraded access.
I've fixed mount.nfs to scan from the beginning. For mountd,
it does not advertise AUTH_NULL anymore. This is necessary
to avoid backward compatibility issue. If AUTH_NULL appears
in the list, either the new or the old client will choose
that over AUTH_SYS.
Tested the server/client combination against the previous
versions, as well as Solaris and FreeBSD.
Signed-off-by: bc Wong <[email protected]>
Cheers,
bc
---
utils/mount/nfsmount.c | 13 ++++++++-----
utils/mountd/mountd.c | 9 ++++++++-
2 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/utils/mount/nfsmount.c b/utils/mount/nfsmount.c
index 3d2ebb1..da5c428 100644
--- a/utils/mount/nfsmount.c
+++ b/utils/mount/nfsmount.c
@@ -734,7 +734,7 @@ nfsmount(const char *spec, const char *node, int flags,
#if NFS_MOUNT_VERSION >= 4
mountres3_ok *mountres;
fhandle3 *fhandle;
- int i, *flavor, yum = 0;
+ int i, n_flavors, *flavor, yum = 0;
if (mntres.nfsv3.fhs_status != 0) {
nfs_error(_("%s: %s:%s failed, reason given by
server: %s"),
progname, hostname, dirname,
@@ -743,13 +743,16 @@ nfsmount(const char *spec, const char *node, int flags,
}
#if NFS_MOUNT_VERSION >= 5
mountres = &mntres.nfsv3.mountres3_u.mountinfo;
- i = mountres->auth_flavors.auth_flavors_len;
- if (i <= 0)
+ n_flavors = mountres->auth_flavors.auth_flavors_len;
+ if (n_flavors <= 0)
goto noauth_flavors;
flavor = mountres->auth_flavors.auth_flavors_val;
- while (--i >= 0) {
- /* If no flavour requested, use first simple
+ for (i = 0; i < n_flavors; ++i) {
+ /*
+ * Per RFC2623, section 2.7, we should prefer the
+ * flavour listed first.
+ * If no flavour requested, use the first simple
* flavour that is offered.
*/
if (! (data.flags & NFS_MOUNT_SECFLAVOUR) &&
diff --git a/utils/mountd/mountd.c b/utils/mountd/mountd.c
index 63d5ce1..b006dc6 100644
--- a/utils/mountd/mountd.c
+++ b/utils/mountd/mountd.c
@@ -342,7 +342,14 @@ mount_mnt_3_svc(struct svc_req *rqstp, dirpath
*path, mountres3 *res)
#define AUTH_GSS_KRB5 390003
#define AUTH_GSS_KRB5I 390004
#define AUTH_GSS_KRB5P 390005
- static int flavors[] = { AUTH_NULL, AUTH_UNIX,
AUTH_GSS_KRB5, AUTH_GSS_KRB5I, AUTH_GSS_KRB5P};
+ /*
+ * We should advertise the preferred flavours first. (See RFC 2623
+ * section 2.7.) AUTH_UNIX is arbitrarily ranked over the GSS's.
+ * AUTH_NULL is dropped from the list to avoid backward compatibility
+ * issue with older Linux clients, who inspect the list in reversed
+ * order.
+ */
+ static int flavors[] = { AUTH_UNIX, AUTH_GSS_KRB5,
AUTH_GSS_KRB5I, AUTH_GSS_KRB5P };
struct nfs_fh_len *fh;
xlog(D_CALL, "MNT3(%s) called", *path);
--
1.5.2.5
Hi BC-
On Mar 6, 2008, at 10:08 PM, bc Wong wrote:
> There were 2 things wrong with auth flavour ordering:
> - Mountd used to advertise AUTH_NULL as the first flavour on
> the list, which means that it prefers AUTH_NULL to anything
> else (as per RFC 2623 section 2.7).
> - Mount.nfs used to scan the returned list in reverse order,
> and stopping at the first AUTH_NULL or AUTH_SYS encountered.
> If a server advertises (AUTH_SYS, AUTH_NULL), it will by
> default choose AUTH_NULL and have degraded access.
This patch addresses problems only in the legacy part of the user
space mount.nfs command. Since 2.6.24 NFS mount option parsing is
handled in the kernel instead.
I don't think the new in-kernel mount client even supports receiving
a list of auth flavors from the server. Do you have an equivalent
patch for that? If you'd like help we can discuss it off-line.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Fri, Mar 7, 2008 at 8:16 AM, Chuck Lever <[email protected]> wrote:
> Hi BC-
>
>
> On Mar 6, 2008, at 10:08 PM, bc Wong wrote:
> > There were 2 things wrong with auth flavour ordering:
> > - Mountd used to advertise AUTH_NULL as the first flavour on
> > the list, which means that it prefers AUTH_NULL to anything
> > else (as per RFC 2623 section 2.7).
> > - Mount.nfs used to scan the returned list in reverse order,
> > and stopping at the first AUTH_NULL or AUTH_SYS encountered.
> > If a server advertises (AUTH_SYS, AUTH_NULL), it will by
> > default choose AUTH_NULL and have degraded access.
>
> This patch addresses problems only in the legacy part of the user
> space mount.nfs command. Since 2.6.24 NFS mount option parsing is
> handled in the kernel instead.
>
> I don't think the new in-kernel mount client even supports receiving
> a list of auth flavors from the server. Do you have an equivalent
> patch for that? If you'd like help we can discuss it off-line.
Hi Chuck,
Sorry I was totally unaware of the the migration of option parsing
into the kernel. At first glance, it seems that the client will just
insist on using whatever is specified in `sec=', even thought the
server does not advertise it. The server would probably return an
NFS RPC error, instead of a MOUNT error. I can look into fixing
the kernel client as well.
I'd still like the submitted patch to be considered. It's quite bad
that mount.nfs would encounter (AUTH_SYS, AUTH_NULL) and
pick the latter.
Thanks,
bc
bc Wong wrote:
> On Fri, Mar 7, 2008 at 8:16 AM, Chuck Lever <[email protected]> wrote:
>
>> Hi BC-
>>
>>
>> On Mar 6, 2008, at 10:08 PM, bc Wong wrote:
>> > There were 2 things wrong with auth flavour ordering:
>> > - Mountd used to advertise AUTH_NULL as the first flavour on
>> > the list, which means that it prefers AUTH_NULL to anything
>> > else (as per RFC 2623 section 2.7).
>> > - Mount.nfs used to scan the returned list in reverse order,
>> > and stopping at the first AUTH_NULL or AUTH_SYS encountered.
>> > If a server advertises (AUTH_SYS, AUTH_NULL), it will by
>> > default choose AUTH_NULL and have degraded access.
>>
>> This patch addresses problems only in the legacy part of the user
>> space mount.nfs command. Since 2.6.24 NFS mount option parsing is
>> handled in the kernel instead.
>>
>> I don't think the new in-kernel mount client even supports receiving
>> a list of auth flavors from the server. Do you have an equivalent
>> patch for that? If you'd like help we can discuss it off-line.
>>
>
> Hi Chuck,
>
> Sorry I was totally unaware of the the migration of option parsing
> into the kernel. At first glance, it seems that the client will just
> insist on using whatever is specified in `sec=', even thought the
> server does not advertise it. The server would probably return an
> NFS RPC error, instead of a MOUNT error. I can look into fixing
> the kernel client as well.
>
> I'd still like the submitted patch to be considered. It's quite bad
> that mount.nfs would encounter (AUTH_SYS, AUTH_NULL) and
> pick the latter.
I don't think that the client can generate AUTH_NONE, can it? I thought
that the client generated AUTH_SYS even if the server specified AUTH_NONE?
If you make changes in this area, please ensure that the server exporting
AUTH_NONE still works.
Thanx...
ps
bc Wong wrote:
> On Fri, Mar 7, 2008 at 8:16 AM, Chuck Lever <[email protected]> wrote:
>
>> Hi BC-
>>
>>
>> On Mar 6, 2008, at 10:08 PM, bc Wong wrote:
>> > There were 2 things wrong with auth flavour ordering:
>> > - Mountd used to advertise AUTH_NULL as the first flavour on
>> > the list, which means that it prefers AUTH_NULL to anything
>> > else (as per RFC 2623 section 2.7).
>> > - Mount.nfs used to scan the returned list in reverse order,
>> > and stopping at the first AUTH_NULL or AUTH_SYS encountered.
>> > If a server advertises (AUTH_SYS, AUTH_NULL), it will by
>> > default choose AUTH_NULL and have degraded access.
>>
>> This patch addresses problems only in the legacy part of the user
>> space mount.nfs command. Since 2.6.24 NFS mount option parsing is
>> handled in the kernel instead.
>>
>> I don't think the new in-kernel mount client even supports receiving
>> a list of auth flavors from the server. Do you have an equivalent
>> patch for that? If you'd like help we can discuss it off-line.
>>
>
> Hi Chuck,
>
> Sorry I was totally unaware of the the migration of option parsing
> into the kernel. At first glance, it seems that the client will just
> insist on using whatever is specified in `sec=', even thought the
> server does not advertise it. The server would probably return an
> NFS RPC error, instead of a MOUNT error. I can look into fixing
> the kernel client as well.
>
>
Actually, NFS servers that support AUTH_NONE, map the uid and gid to the
anonymous uid and gids for access to file systems which are exported
AUTH_NONE. It doesn't seem to matter what authentication flavor that
the client uses.
ps
> I'd still like the submitted patch to be considered. It's quite bad
> that mount.nfs would encounter (AUTH_SYS, AUTH_NULL) and
> pick the latter.
>
> Thanks,
> bc
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Fri, Mar 7, 2008 at 10:29 AM, Peter Staubach <[email protected]> wrote:
> Actually, NFS servers that support AUTH_NONE, map the uid and gid to the
> anonymous uid and gids for access to file systems which are exported
> AUTH_NONE. It doesn't seem to matter what authentication flavor that
> the client uses.
>
> ps
Hi Peter,
My concern is that a server supports both AUTH_SYS and AUTH_NONE,
where AUTH_SYS would give you the regular access, and AUTH_NONE
would give the anon access as you described, which is typically a
degraded read-only view. Therefore it's bad for the client to choose
AUTH_NONE in this case, especially since the server presents
AUTH_SYS *before* AUTH_NONE.
I'll test more with AUTH_NONE on Solaris. Is there any specific setup
you'd like me to verify?
Thanks,
bc
bc Wong wrote:
> On Fri, Mar 7, 2008 at 10:29 AM, Peter Staubach <[email protected]> wrote:
>
>> Actually, NFS servers that support AUTH_NONE, map the uid and gid to the
>> anonymous uid and gids for access to file systems which are exported
>> AUTH_NONE. It doesn't seem to matter what authentication flavor that
>> the client uses.
>>
>> ps
>>
>
> Hi Peter,
>
> My concern is that a server supports both AUTH_SYS and AUTH_NONE,
> where AUTH_SYS would give you the regular access, and AUTH_NONE
> would give the anon access as you described, which is typically a
> degraded read-only view. Therefore it's bad for the client to choose
> AUTH_NONE in this case, especially since the server presents
> AUTH_SYS *before* AUTH_NONE.
>
> I'll test more with AUTH_NONE on Solaris. Is there any specific setup
> you'd like me to verify?
Do you know of any client NFS implementations that can actually generate
requests with AUTH_NONE as the authentication flavor? Which server
implementation supports the mode that you described?
As far as I know, all servers, which support exporting with AUTH_NONE,
always map the incoming uid and gid(s) to the anonymous uid and gid when
they process the request for a file system which is exported with AUTH_NONE.
It doesn't seem to matter what the incoming authentication flavor was.
Thanx...
ps
On Fri, Mar 7, 2008 at 11:10 AM, Peter Staubach <[email protected]> wrote:
>
> bc Wong wrote:
> > On Fri, Mar 7, 2008 at 10:29 AM, Peter Staubach <[email protected]> wrote:
> >
> >> Actually, NFS servers that support AUTH_NONE, map the uid and gid to the
> >> anonymous uid and gids for access to file systems which are exported
> >> AUTH_NONE. It doesn't seem to matter what authentication flavor that
> >> the client uses.
> >>
> >> ps
> >>
> >
> > Hi Peter,
> >
> > My concern is that a server supports both AUTH_SYS and AUTH_NONE,
> > where AUTH_SYS would give you the regular access, and AUTH_NONE
> > would give the anon access as you described, which is typically a
> > degraded read-only view. Therefore it's bad for the client to choose
> > AUTH_NONE in this case, especially since the server presents
> > AUTH_SYS *before* AUTH_NONE.
> >
> > I'll test more with AUTH_NONE on Solaris. Is there any specific setup
> > you'd like me to verify?
>
> Do you know of any client NFS implementations that can actually generate
> requests with AUTH_NONE as the authentication flavor? Which server
> implementation supports the mode that you described?
Hi Peter,
Linux does that. 2.6.22. The reason I submitted this patch is that I ran
into this bug. My server advertises (AUTH_SYS, AUTH_NONE), with
AUTH_NONE giving degraded access. The older clients are ok, since
mount.nfs enforces the AUTH_SYS default. Then a new client (2.6.22)
came in and I went scratching my head why it's using AUTH_NONE.
Cheers,
bc
> As far as I know, all servers, which support exporting with AUTH_NONE,
> always map the incoming uid and gid(s) to the anonymous uid and gid when
> they process the request for a file system which is exported with AUTH_NONE.
> It doesn't seem to matter what the incoming authentication flavor was.
>
> Thanx...
>
> ps
>
bc Wong wrote:
> On Fri, Mar 7, 2008 at 11:10 AM, Peter Staubach <[email protected]> wrote:
>
>> bc Wong wrote:
>> > On Fri, Mar 7, 2008 at 10:29 AM, Peter Staubach <[email protected]> wrote:
>> >
>> >> Actually, NFS servers that support AUTH_NONE, map the uid and gid to the
>> >> anonymous uid and gids for access to file systems which are exported
>> >> AUTH_NONE. It doesn't seem to matter what authentication flavor that
>> >> the client uses.
>> >>
>> >> ps
>> >>
>> >
>> > Hi Peter,
>> >
>> > My concern is that a server supports both AUTH_SYS and AUTH_NONE,
>> > where AUTH_SYS would give you the regular access, and AUTH_NONE
>> > would give the anon access as you described, which is typically a
>> > degraded read-only view. Therefore it's bad for the client to choose
>> > AUTH_NONE in this case, especially since the server presents
>> > AUTH_SYS *before* AUTH_NONE.
>> >
>> > I'll test more with AUTH_NONE on Solaris. Is there any specific setup
>> > you'd like me to verify?
>>
>> Do you know of any client NFS implementations that can actually generate
>> requests with AUTH_NONE as the authentication flavor? Which server
>> implementation supports the mode that you described?
>>
>
> Hi Peter,
>
> Linux does that. 2.6.22. The reason I submitted this patch is that I ran
> into this bug. My server advertises (AUTH_SYS, AUTH_NONE), with
> AUTH_NONE giving degraded access. The older clients are ok, since
> mount.nfs enforces the AUTH_SYS default. Then a new client (2.6.22)
> came in and I went scratching my head why it's using AUTH_NONE.
>
>
Well, so it does. Sorry, when that patch was developed, the client
would not
generate an AUTH_NONE request and could not handle servers which
exported using
only AUTH_NONE.
It would be good to ensure that they continue to work.
Thanx...
ps
> Cheers,
> bc
>
>
>> As far as I know, all servers, which support exporting with AUTH_NONE,
>> always map the incoming uid and gid(s) to the anonymous uid and gid when
>> they process the request for a file system which is exported with AUTH_NONE.
>> It doesn't seem to matter what the incoming authentication flavor was.
>>
>> Thanx...
>>
>> ps
>>
>>
On Fri, Mar 7, 2008 at 12:28 PM, Peter Staubach <[email protected]> wrote:
<snip>
> It would be good to ensure that they continue to work.
>
> Thanx...
>
> ps
Hi,
I tested the original patch against the Solaris AUTH_NONE server
setup. It works. Two cases specifically:
(1) share -F nfs -o sec=none <export>
(2) share -F nfs -o sec=sys:none,anon=-1 <export>
(1) works both before and after. Client uses AUTH_NONE. (2) would
cause degraded client access before (using AUTH_NONE), but works
after the patch (using AUTH_SYS).
Thanks,
bc