Re: [PATCH] nfs-utils: Handle authentication flavour order properly

[Peter Staubach <staubach@redhat.com>]

bc Wong wrote:
> On Fri, Mar 7, 2008 at 8:16 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
>   
>> Hi BC-
>>
>>
>>  On Mar 6, 2008, at 10:08 PM, bc Wong wrote:
>>  > There were 2 things wrong with auth flavour ordering:
>>  > - Mountd used to advertise AUTH_NULL as the first flavour on
>>  >   the list, which means that it prefers AUTH_NULL to anything
>>  >   else (as per RFC 2623 section 2.7).
>>  > - Mount.nfs used to scan the returned list in reverse order,
>>  >   and stopping at the first AUTH_NULL or AUTH_SYS encountered.
>>  >   If a server advertises (AUTH_SYS, AUTH_NULL), it will by
>>  >   default choose AUTH_NULL and have degraded access.
>>
>>  This patch addresses problems only in the legacy part of the user
>>  space mount.nfs command.  Since 2.6.24 NFS mount option parsing is
>>  handled in the kernel instead.
>>
>>  I don't think the new in-kernel mount client even supports receiving
>>  a list of auth flavors from the server.  Do you have an equivalent
>>  patch for that?  If you'd like help we can discuss it off-line.
>>     
>
> Hi Chuck,
>
> Sorry I was totally unaware of the the migration of option parsing
> into the kernel. At first glance, it seems that the client will just
> insist on using whatever is specified in `sec=', even thought the
> server does not advertise it. The server would probably return an
> NFS RPC error, instead of a MOUNT error. I can look into fixing
> the kernel client as well.
>
> I'd still like the submitted patch to be considered. It's quite bad
> that mount.nfs would encounter (AUTH_SYS, AUTH_NULL) and
> pick the latter.

I don't think that the client can generate AUTH_NONE, can it?  I thought
that the client generated AUTH_SYS even if the server specified AUTH_NONE?

If you make changes in this area, please ensure that the server exporting
AUTH_NONE still works.

    Thanx...

       ps