Re: Security negotiation

Chuck Lever
2009-07-10T18:57:29Z

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