Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user

[Trond Myklebust <trond.myklebust@fys.uio.no>]

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