On Aug 21, 2009, at 4:04 PM, J. Bruce Fields wrote:
On Fri, Aug 21, 2009 at 02:46:28PM -0400, Chuck Lever wrote:
On Aug 21, 2009, at 2:24 PM, J. Bruce Fields wrote:
On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
I want to understand the server bug a little more. I glanced over
RFC
2623 and didn't see anything specific.
Is it the case that only Linux NFSD does this, or do other
servers do
it? In other words, is this a typical server response, and if
so, is
there a specific semantic attached to it?
If no list is provided, should the client assume that only
AUTH_NONE
and
AUTH_SYS are supported, or instead, perhaps that the client can try
to
use any flavor? In other words, if no list is provided, let the
mount
proceed no matter what was specified by sec= ?
I think the safest behavior on the client would be something like:
- If an explicit sec= is provided on the client, try that
flavor. Otherwise:
- If the server returned a nonempty list, pick something
off that list. Otherwise:
- Try auth_sys.
Right now, we use AUTH_SYS if the mount command didn't specify a
flavor,
but the flavor we're going to use is always checked against the
server's
returned list. You seem to be suggesting we should ignore the
server's
list entirely if sec= was specified...?
Yes. I can't see what practical problems that would cause.
Well, it would mean our client isn't up to spec, confusing people who
need to modify that code and people who expect a sec=krb5 mount to
fail immediately if the server says it can't support AUTH_GSS_KRB5.
It may also not match the behavior of the legacy mount command on Linux.
Also, while I hope this is the last bug in the mountd's flavor list
return, it isn't the first--only recently did we even start using real
information from the export instead of just faking something up. So I
think it's safest to preserve the historical sec= behavior and give
users a way to override the negotiation, to cut down on bug reports of
mount failures on upgrade.
OK, if this is a recently introduced server problem, then why do we
need to adjust client-side behavior? Trond's response in cases like
this is usually "fix the d*mn server," which you've already done.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
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
