Re: Security negotiation

Chuck Lever
2009-07-10T20:11:17Z

On Jul 10, 2009, at 2:57 PM, Chuck Lever wrote:

>
> On Jul 10, 2009, at 2:07 PM, Tom Haynes wrote:
>
>> During a NFSv3 mount request, the server returns an array of
>> supported security flavors.
>>
>> With a Linux server, exports(5) states:
>>
>> For the purposes of security flavor negotiation, order counts:
>> preferred flavors should be listed first.
>>
>> And the Solaris client states in mount_nfs(1M):
>>
>> NFS Version 3 mounts negotiate a security mode when the server
>> returns an array of security modes. The
>> client picks the first mode in the array that is supported on the
>> client. In negotiations, an NFS Version 3 client
>> is limited to the security flavors listed in /etc/nfssec.conf.
>>
>> The Linux nfs(5) states:
>>
>> If the sec option is not specified, or if sec=sys is specified,
>> the NFS client uses the AUTH_SYS
>> security flavor for all NFS requests on this mount point.
>>
>> So, I'm trying to understand what the Linux client would do if the
>> export does not support AUTH_SYS and
>> there is no sec= supplied.
>>
>> Does the Linux client traverse the array in order until it finds a
>> match or does it consider which flavor is strongest?
>
> The legacy mount command does this (kernels earlier than 2.6.23) but
> the kernel mount client does not yet. I intend to submit patches
> for this (today, actually) for 2.6.32.
>
> The patches will walk the auth_list returned by mountd. By default
> it will look for AUTH_SYS, otherwise it will look for the flavor
> specified by the sec= mount option.
>
> If mountd does not provide AUTH_SYS a mount request with no sec=
> will fail. Should it try the first one in the list instead? What
> if the first one is AUTH_NULL?

In other words, I'm not sure what is the right behavior here. What it
does now is probably suboptimal. I've browsed 2623 a bit, but it's
not hitting me.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com