From: "J. Bruce Fields" <bfields@fieldses.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>, linux-nfs@vger.kernel.org
Subject: Re: [PATCH] NFS: Change default behavior when "sec=" is not specified by user
Date: Tue, 1 Sep 2009 16:15:44 -0400 [thread overview]
Message-ID: <20090901201544.GF27726@fieldses.org> (raw)
In-Reply-To: <E7FCF468-0A25-4DA1-8E71-A383BCBA4642@oracle.com>
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.
--b.
next prev parent reply other threads:[~2009-09-01 20:15 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-01 14:31 [PATCH] NFS: Change default behavior when "sec=" is not specified by user Chuck Lever
[not found] ` <20090901143012.3978.11441.stgit-RytpoXr2tKZ9HhUboXbp9zCvJB+x5qRC@public.gmane.org>
2009-09-01 15:05 ` J. Bruce Fields
2009-09-01 15:10 ` Chuck Lever
2009-09-01 15:18 ` J. Bruce Fields
2009-09-01 15:52 ` Chuck Lever
2009-09-01 16:09 ` J. Bruce Fields
2009-09-01 16:29 ` Chuck Lever
2009-09-01 16:38 ` J. Bruce Fields
2009-09-01 18:07 ` Chuck Lever
2009-09-01 18:21 ` J. Bruce Fields
2009-09-01 18:25 ` Trond Myklebust
[not found] ` <1251829540.18608.31.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-09-01 18:28 ` Trond Myklebust
[not found] ` <1251829737.18608.34.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-09-01 18:35 ` Trond Myklebust
2009-09-01 18:58 ` Chuck Lever
2009-09-01 19:31 ` Trond Myklebust
[not found] ` <1251833479.18608.69.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-09-01 19:33 ` Trond Myklebust
2009-09-01 20:10 ` Chuck Lever
2009-09-01 20:15 ` J. Bruce Fields [this message]
2009-09-01 20:31 ` Chuck Lever
2009-09-01 21:22 ` Trond Myklebust
[not found] ` <1251840160.8463.20.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2009-09-02 14:16 ` Chuck Lever
2009-09-01 18:33 ` Peter Staubach
2009-09-01 18:50 ` J. Bruce Fields
2009-09-01 18:52 ` Peter Staubach
2009-09-01 19:16 ` J. Bruce Fields
2009-09-01 19:24 ` Peter Staubach
2009-09-01 20:05 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090901201544.GF27726@fieldses.org \
--to=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox