|
Description
|
There is a bug in Linux NFSv3 servers mountd implementation where in mountd advertises AUTH_NONE as the first prefered flavor to NFS clients. This behavior of Linux was casuing Solaris clients to NFS mount the file system with AUTH_NONE flavor. As per mount_nfs man page:
<man page snip>
NFS Version 3 mounts negotiate a security mode when
the server returns an array of security modes. The
client picks the first mode in the array that is
supported on the client. In negotiations, an NFS
Version 3 client is limited to the security flavors
listed in /etc/nfssec.conf.
<end man page snip>
This can cause confusion among end users as they will be having user "nobody" privilages. Linux NFS community has acknowledged this bug and have fixed it in their implementation.
<email snip>
commit 3c1bb23c0379864722e79d19f74c180edcf2c36e
Author: bc Wong < xxxxx@xxxxx.com>
Date: Tue Mar 18 09:30:44 2008 -0400
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 < xxxxx@xxxxx.com>
Signed-off-by: Steve Dickson < xxxxx@xxxxx.com>
<end email snip>
We should make the Solaris client more robust to situations like this.
|