On Fri, 2009-08-21 at 16:59 -0400, J. Bruce Fields wrote: > On Fri, Aug 21, 2009 at 04:39:53PM -0400, Peter Staubach wrote: > > Tom Haynes wrote: > > > J. Bruce Fields wrote: > > >> > > >>> 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. > > >> > > > > Here, I am going to disagree. The client should compare the > > flavor specified with the list of authentication flavors > > returned by the server and if the specific flavor isn't on > > the list, then the mount attempt should be failed. > > Why? What can go wrong if you just try the flavor? > > Ugh: to answer my own question: ok, if the server allows auth_sys for > the NFS operations required on mount (as suggested by the security > considerations rfc), then that would mean mount would always succeed, > and nobody would see the error until the first operation on the > filesystem. It would be better to return the error on mount. > > So, I think I have to give in and agree with you. People will just have > to upgrade their mountd's.... People have lived with the current situation for years without any trouble. It was only the addition of the security negotiation that exposed the mountd bug. My position is that if mountd returns a clearly invalid (i.e. empty) list, then that's not a reason to interrupt the mount. We should just fall back to what we did prior to including security negotiation. The alternative is simply not to merge security negotiation until people have had ample time to upgrade mountd (i.e. 2-3 years from now). Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.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
