J. Bruce Fields wrote:
On Mon, Aug 11, 2008 at 04:51:26PM -0400, Peter Staubach wrote:
The Solaris client behaves plus or minus like the Linux client.
It generates a GETATTR unless it receives the attributes via
one of the previous calls. In the Solaris case, it is an FSINFO
call.
The current Linux NFS server does not return attributes for the
PATHCONF, FSINFO, or FSSTAT calls.
Hm. I don't know why that is.
Unless these calls are modified, then the NFSv3 GETATTR will need
to be allowed for the same reason that the NFSv2 GETATTR is
allowed. The NFS client needs, at the very least, the file type
of the node that it is mounting.
I am confused as to how the testing could have been successful.
Well, you can try exporting a filesystem with sec=krb5:krb5i:krb5p (no
sys) and try mounting v2 or v3, and you'll see that if fails without the
patch, and succeeds with it.
But testing again (linux client and server), and taking a network trace
this time: I mount with -overs=3,sec=krb5, and the client behavior is
odd:
FSINFO call with auth_sys
GETATTR call with krb5
FSINFO call with krb5
Note that this client actually *does* have access to kerberos
credentials--it's just not using them on the initial FSINFO call.
What happens if you perform this mount using autofs?
Thanx...
ps
That could make some sense if it was trying to ensure the mount will
succeed in the absence of kerberos credentials, and doesn't want to
bother first trying to get a credentials and then falling back on
auth_sys if it doesn't find them.
But currently it fails if the server requests auth_sys on the initial
FSINFO *or* if it fails to get kerberos credentials for those second two
rpc calls. Something similar seems to be true for v2. Huh.
Anyway, so in the Solaris v3 case I take it that what you're seeing is
FSINFO, GETATTR, both done with auth_sys, and a failure of the mount
command if both aren't permitted?
OK, so I agree the server should either permit v3 GETATTR (trivial, if
arguably contrary to rfc 2623) or add attributes to FSINFO (which I
assume is also easy, but I don't know why it was left out before).
Seems the client needs some looking at too.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
