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. 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. --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
