Re: [PATCH 06/11] nfs-utils: mount: AUTH_NONE mounts

[Peter Staubach <staubach@redhat.com>]

Neil Brown wrote:
> On Tuesday February 27, staubach@redhat.com wrote:
>   
>> Neil Brown wrote:
>>     
>>> On Monday February 26, SteveD@redhat.com wrote:
>>>   
>>>       
>>>> commit 0ffd74c990aca3761b79316d47e1b1778273681c
>>>> Author: Steve Dickson <steved@redhat.com>
>>>> Date:   Sat Feb 24 15:27:46 2007 -0500
>>>>
>>>>     Added support to specify the AUTH_NONE security flavor (i.e. -o sec=none)
>>>>     
>>>>         
>>> If you specify "-o sec=none" then data.pseudoflavor will == AUTH_NONE,
>>> but
>>>
>>>   
>>>       
>> This support is being added so that the client can mount a file system
>> which was exported with sec=none.
>>     
>
> Ok, so the Changelog comment could be improved...
>
>   
>> This loop is looking for AUTH_NONE in the list of authentication
>> flavors that the server supports and was returned through the MOUNT
>> protocol during mounting.
>>
>> Basically, if the server file system is exported with AUTH_NONE, then
>> it doesn't matter what flavor that the client chooses, the server will
>> always map it to AUTH_NONE and all requests will be processed with the
>> anonymous uid and gid.
>>     
>
> I still don't understand (sorry if I am being dense).
> Surely a server could export a filesystem as AUTH_NONE or AUTH_UNIX or
> krbi.  And it could matter a lot what auth the client uses because if
> it uses AUTH_NONE it would have access to many fewer files than
> e.g. AUTH_UNIX.
>
> And surely if I mount with "-o sec=krbi", and the server only supports
> AUTH_NONE, then the mount should fail.  But with the patch as given, I
> think it will succeed.  What am I missing?
>
> What exactly is the situation where the current code does the wrong
> thing, and the new code does the right thing?

The current code looks through the list of supported authentication
flavors returned from the server and through its own list of supported
flavors to try to find one that matches.  Since the client does not
support AUTH_NONE, then none match and the mount attempt fails.

Actually, the implementation appears to be that if the server exports
with AUTH_NONE, then it will take any flavor of authentication on the
incoming request, but then use AUTH_NONE for itself.

Since the server is exporting with AUTH_NONE, all incoming requests
are processed using the anonymous uid and gid, and yes, should have
reduced access.

This was used to address RH bz187370.

    Thanx...

       ps

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs