On Aug 21, 2009, at 5:30 PM, J. Bruce Fields wrote:
On Fri, Aug 21, 2009 at 05:15:45PM -0400, Trond Myklebust wrote:
On Fri, 2009-08-21 at 16:36 -0400, Chuck Lever wrote:
On Aug 21, 2009, at 4:04 PM, J. Bruce Fields wrote:
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.
What is the definition of "recently introduced" here? What is the
exact
commit that introduced the bug in nfs-utils?
By the way, looking at 'gitk utils/mountd/mountd.c' in my tree:
Originally (didn't look to see how far it goes back), mountd
returned AUTH_NULL, AUTH_UNIX, in that order.
1999, at least. That's when nfs-utils was imported into a source
control system, which was later moved to git.
53c5bd65c74, first in 1.0.8, always returns
AUTH_NULL, AUTH_UNIX, AUTH_GSS_KRB5, AUTH_GSS_KRB5I,
AUTH_GSS_KRB5P, in that order.
3c1bb23c037, first in 1.1.3, removes AUTH_NULL from that static
list.
603017f2c15, first in 1.1.4, derives the psuedoflavor list from
the export (and introduces the above bug).
1.1.4 was released October 14, 2008. I'm sure it was a month or two
before distributions picked it up.
The latest patch, not yet in Steve's repo, fixes the empty flavor
list.
For the rest of eternity, mountd is perfect.
Having the client ignore flavor checking if the returned auth flavor
list is empty is easy. We should check the behavior of the legacy
mount command too.
--
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
