On Sep 1, 2009, at 4:15 PM, J. Bruce Fields wrote:
On Tue, Sep 01, 2009 at 04:10:57PM -0400, Chuck Lever wrote:
On Sep 1, 2009, at 3:31 PM, Trond Myklebust wrote:
As I said, this functionality is in also required in order to make
NFSv4
security negotiation work.
This is all added to the kernel's MNT client. None of this logic
will
ever be used by NFSv4, unless we refactor it someday. At which
time, we
can worry about it then.
...and for NFSv2 as well...
Now you've lost me. The v1 MNTPROC doesn't return a flavor list, so
NFSv2 doesn't support security flavor negotiation at mount time.
The protocol doesn't have explicit support for it, just as NFSv4.0
doesn't in the case of security on /, but we can still support a
form of
"negotiation" in both cases by doing a linear search through the
supported flavors and trying each one.
I agree that we should do that. I don't think it necessarily needs to
be done *before* any of the other changes that have been discussed, so
it could be done as a second step.
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.
--
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
