On Tue, 2009-09-01 at 16:31 -0400, Chuck Lever wrote: > For v4, you have WRONGSEC, but I don't think NFSv2 makes that > distinction. Would the client probe the server with NFS requests each > using a different flavor? Would we expect to see the RPC level "weak > authentication" reply in the NFSv2 case? Before Eisler says it, why > would we bother? > > Even so, that's a much different proposition than simply reading the > flavor list returned by MNT3PROC, so I'm straining to see how we could > reuse the logic I'm adding to the kernel's MNT client to do security > negotiation for NFSv2. If Trond is referring only to merging the > kernel's auth flavor lists, then that comment makes more sense. IMO the goal should be to have _one_ engine that can iterate through a list of auth flavours (either the list provided by the MNT server, or the list of all flavours supported by the client) until it gets a positive response to an RPC call. We shouldn't assume that the flavour that was negotiated at mount time is final. It makes sense to code this iteration process at the RPC level instead of at the NFS level. That enables us to use the same engine for NFSv2, NFSv4, and the NFSv4.0 server (when doing client callbacks). Possibly also for NLM and MOUNT (apparently IRIX used to support this)... -- 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
