Re: Security negotiation

[Chuck Lever <chuck.lever@oracle.com>]

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?

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