Andrew Gallatin wrote:
>
> Speaking of this, it seemed like there was confusion at the time
> of the original thread whether having the client prefer AUTH_NONE
> when AUTH_SYS was also offered is actually required by any standard.
>
> Recent OpenSolaris seems to be the only OS that does this, and
> doing so really feels like a bug.
>
> Drew
The bug in OpenSolaris is that it does not consider the default security
flavor in /etc/nfssec.conf.
You could consider that Linux also has a bug, as exports(5) states:
For the purposes of security flavor negotiation, order counts:
preferred flavors should be listed first.
I.e.:
[tdh at adept ~]> exportfs
/home 192.168.2.0/255.255.255.0
/ <world>
[tdh at adept ~]> more /etc/exports
/ *(sync)
/home
192.168.2.0/255.255.255.0(rw,async,no_subtree_check,insecure,no_root_squash)
And on the mount:
MOUNT:----- NFS MOUNT -----
MOUNT:
MOUNT:Proc = 1 (Add mount entry)
MOUNT:Status = 0 (OK)
MOUNT:File handle = [DADF]
MOUNT: 01000700010005000000000053CF6DE4FF1C4572BB2950392EB6993C
MOUNT:Authentication flavor = none,unix,390003,390004,390005
MOUNT:
The Linux server is stating that it would prefer that the client uses
AUTH_NONE to
establish the mount.
And the way the Linux client treats this is via nfs(5):
If the sec option is not specified, or if sec=sys is specified, the
NFS client uses the AUTH_SYS
security flavor for all NFS requests on this mount point.
It ignores the list of flavors (and indeed, not all of the flavors are
valid, at least not on my system).
