On 06/28/2011 03:34 PM, Chuck Lever wrote:
>
> On Jun 28, 2011, at 3:10 PM, J. Bruce Fields wrote:
>
>> On Tue, Jun 28, 2011 at 03:06:40PM -0400, bfields wrote:
>>> On Tue, Jun 28, 2011 at 02:25:41PM -0400, Chuck Lever wrote:
>>>> There is an undocumented convention (verified by reviewing network
>>>> traces from a NetApp filer and a Solaris NFS server) where a server
>>>> that returns a mount authflavor list containing an AUTH_NULL entry
>>>> is actually indicating it will accept any security flavor for the
>>>> export being mounted.
>>>
>>> This is only in the case of NLM? (Not v4 secinfo?)
>> ^^^
>> (Sorry, I meant MOUNT !)
>
> Right, this fix is specifically for the kernel's NFSv3 mount client. I expect that SECINFO is probably the area where NFSv4 spec changes might help, but I haven't touched that in these patches.
>
> At some point Bryan, Trond, and I should discuss how we can unify these pieces, and teach them how to determine the list of locally supported authflavors. Maybe this is done already?
Do you mean something similar to gss_mech_list_pseudoflavors() in net/sunrpc/auth_gss/gss_mech_switch.c? I use it to determine the sec flavor of an NFS v4.0 mount if AUTH_SYS fails (see nfs4_find_root_sec() in fs/nfs/nfs4proc.c)
- Bryan
>
>>>
>>> --b.
>>>
>>>>
>>>> This might be used when the server maps all security flavors into the
>>>> same security mode. For example, the server treats all accessors as,
>>>> say, UID 17.
>>>>
>>>> Essentially, AUTH_NULL is treated as a wildcard that matches the
>>>> flavor the mounter requested.
>>>>
>>>> Signed-off-by: Chuck Lever <chuck.lever@xxxxxxxxxx>
>>>> ---
>>>>
>>>> fs/nfs/super.c | 15 +++++++++++----
>>>> 1 files changed, 11 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/fs/nfs/super.c b/fs/nfs/super.c
>>>> index 4625a4c..543cf9f 100644
>>>> --- a/fs/nfs/super.c
>>>> +++ b/fs/nfs/super.c
>>>> @@ -1570,13 +1570,20 @@ static int nfs_walk_authlist(struct nfs_parsed_mount_data *args,
>>>> * the first flavor in the list that it supports, on the
>>>> * assumption that the best access is provided by the first
>>>> * flavor."
>>>> + *
>>>> + * By convention we treat AUTH_NULL in the returned list as
>>>> + * a wild card. The server will map our requested flavor to
>>>> + * something else.
>>>> */
>>>> - for (i = 0; i < args->auth_flavor_len; i++)
>>>> - for (j = 0; j < server_authlist_len; j++)
>>>> - if (args->auth_flavors[i] == server->auth_flavs[j]) {
>>>> - args->auth_flavors[0] = server->auth_flavs[j];
>>>> + for (i = 0; i < server_authlist_len; i++) {
>>>> + if (server->auth_flavs[i] == RPC_AUTH_NULL)
>>>> + goto out;
>>>> + for (j = 0; j < args->auth_flavor_len; j++)
>>>> + if (server->auth_flavs[i] == args->auth_flavors[j]) {
>>>> + args->auth_flavors[0] = server->auth_flavs[i];
>>>> goto out;
>>>> }
>>>> + }
>>>>
>>>> dfprintk(MOUNT, "NFS: server does not support requested auth flavor\n");
>>>> nfs_umount(server);
>>>>
>>>> --
>>>> 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
>
--
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
