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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux