Andrew Gallatin wrote:
OK, I just got the mail. The bug is 6828396
Its odd that the Solaris bug reporter doesn't actually assign a number until later.
Other bug reporters (Apple's, for example) give you a number as soon as you hit
"submit". Does a human actually look at the bug before it is given a number?
Drew
Hi Drew,
Looking at snoop output for NFS v3 mount from a solaris client, we have:
5 0.00156 solaris-client -> linux-server MOUNT3 C Mount /v3-server-test
6 0.00859 linux-server -> solaris-client MOUNT3 R Mount OK FH=5F67
Auth=none,unix,390003,390004,390005
Linux server replies back to Solaris client saying it supports AUTH_NONE and AUTH_SYS authentication mechanism. mount_nfs continues its execution on client machine and mounts remote file system as AUTH_NONE.
bash-3.2# nfsstat -m /mnt
/mnt from linux-server:/v3-server-test
Flags:
vers=3,proto=tcp,sec=none,hard,intr,link,symlink,acl,rsize=32768,wsize=32768,retrans=5,timeo=600
Attr cache: acregmin=3,acregmax=60,acdirmin=30,acdirmax=60
With integration of CR 6790413 <http://monaco.sfbay/detail.jsf?cr=6790413>, we
now have AUTH_NONE being used for authentication.
6790413 <http://monaco.sfbay/detail.jsf?cr=6790413> AUTH_NONE implementation in
kernel
Prior to CR 6790413 <http://monaco.sfbay/detail.jsf?cr=6790413>, Solaris NFS
clients used to send AUTH_SYS even for AUTH_NONE authentications.
switch (authflavor) {
case AUTH_NONE:
/*
* XXX: should do real AUTH_NONE, instead of AUTH_UNIX
*/
case AUTH_UNIX:
*ap = (AUTH *) authkern_create();
return ((*ap != NULL) ? 0 : EINTR);
From RPC RFC:
-------------
<snip>
9.1 Null Authentication
Often calls must be made where the client does not care about its
identity or the server does not care who the client is. In this
case, the flavor of the RPC message's credential, verifier, and reply
verifier is "AUTH_NONE". Opaque data associated with "AUTH_NONE" is
undefined. It is recommended that the length of the opaque data be
zero.
<end snip>
Solaris servers take care of this issue as documented in share_nfs man page:
<snip>
sec=none If the option sec=none is specified
when the client uses AUTH_NONE, or
if the client uses a security mode
that is not one that the file system
is shared with, then the credential
of each NFS request is treated as
unauthenticated. See the anon=uid
option for a description of how
unauthenticated requests are han-
dled.
<end snip>
<snip>
anon=uid Set uid to be the effective user ID
of unknown users. By default,
unknown users are given the effec-
tive user ID UID_NOBODY. If uid is
set to -1, access is denied.
<end snip>
For this scenario, where we are mounting a file system from Linux Server onto Solaris Client, use "sec=sys" option to force Solaris client to use AUTH_SYS to mount.
bash-3.2# mount -F nfs -o vers=3,sec=sys linux-server:/v3-server-test /mnt
bash-3.2# nfsstat -m /mnt
/mnt from linux-server:/v3-server-test
Flags:
vers=3,proto=tcp,sec=sys,hard,intr,link,symlink,acl,rsize=32768,wsize=32768,retrans=5,timeo=600
Attr cache: acregmin=3,acregmax=60,acdirmin=30,acdirmax=60
From mount_nfs man page on Solaris:
<snip>
sec=mode
Set the security mode for NFS transactions. If sec=
is not specified, then the default action is to use
AUTH_SYS over NFS Version 2 mounts, or to negotiate
a mode over NFS Version 3 or Version 4 mounts.
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.
NFS Version 4 mounts negotiate a security mode when
the server returns an array of security modes. The
client attempts the mount with each security mode,
in order, until one is successful.
Only one mode can be specified with the sec= option.
See nfssec(5) for the available mode options.
<end snip>
As per the man page, Solaris NFS client is exhibiting correct behavior by picking the first mode in the array that is supported on client.
I am closing this CR as not a defect. Please let me know if you have any other
questions.
Regards,
-Vallish
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
