All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Staubach <staubach@redhat.com>
To: Neil Brown <neilb@suse.de>
Cc: nfs@lists.sourceforge.net, Steve Dickson <SteveD@redhat.com>
Subject: Re: [PATCH 06/11] nfs-utils: mount:  AUTH_NONE mounts
Date: Tue, 13 Mar 2007 12:13:25 -0400	[thread overview]
Message-ID: <45F6CDA5.9020607@redhat.com> (raw)
In-Reply-To: <17910.15196.104675.695016@notabene.brown>

Neil Brown wrote:
> On Friday March 2, staubach@redhat.com wrote:
>   
>> Neil Brown wrote:
>>     
>>> On Thursday March 1, staubach@redhat.com wrote:
>>>   
>>>       
>>>> This was used to address RH bz187370.
>>>>     
>>>>         
>>> Thanks for the link.  It provides good context.
>>>
>>> I would have thought the appropriate response would have been the
>>> following patch, and a suggestion to use
>>>   mount -o sec=none .....
>>> to mount the filesystem.
>>> Do you see a problem with that?
>>>       
>> Yes, that's not sufficient.  The client should be able to automatically
>> "do the right thing".  The systems administrator shouldn't have to
>> specify the authentication flavor to match the server flavor.  That
>> systems administrator should only have to specify when there are
>> specific requirements for that client.
>>     
>
> Ok..... so maybe we want "-o sec=" to accept a list of flavours, with
> the default being "-o sec=sys:none".  Would that be suitable?
> We would pick the first one in the server's list that is also in the
> clients list.
> I'm not sure allowing a list to be specified is really needed, so the
> following patch just causes the default to be effectively
> sec=sys:none.
> Would that suit?
>
> I just really don't like the idea of sending NFS requests with
> AUTH_SYS when mountd has said that it only supports AUTH_NONE.
>
>   

I have to admit that aesthetically, sending AUTH_SYS requests instead
of AUTH_NONE seems inelegant, but it works and matches the behavior of
other implementations.
>> And a question, I thought that I looked, and it did not appear that
>> the kernel supported AUTH_NONE on the client side.  Did I miss it?
>>     
>
> Well....
> fs/nfs/super.c:nfs_pseudoflavour_to_name certainly recognises RPC_AUTH_NULL.
> and net/sunrpc/auth.c:auth_flavors has authnull_ops.
> So I suspect the kernel supports it.  I admit I haven't tried.

With a small update to the patch, the kernel seems to _almost_ generate
AUTH_NONE requests.  Interestingly, the kernel makes the first FSINFO
call with AUTH_SYS and then makes another FSINFO call with AUTH_NONE.
Both FSINFO calls suceeded and returned the same information.

The small update to the patch is to add the line:

    data.flags |= NFS_MOUNT_SECFLAVOUR;

after setting data.pseudoflavor to flavor[i].

Anyone know why, off hand, the NFS client needs to make two FSINFO calls?

    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

  reply	other threads:[~2007-03-13 16:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-26 11:18 [PATCH 06/11] nfs-utils: mount: AUTH_NONE mounts Steve Dickson
2007-02-27  6:14 ` Neil Brown
2007-02-27 14:13   ` Peter Staubach
2007-02-28 23:08     ` Neil Brown
2007-03-01 16:10       ` Peter Staubach
2007-03-02  4:01         ` Neil Brown
2007-03-02 15:27           ` Peter Staubach
2007-03-13  5:49             ` Neil Brown
2007-03-13 16:13               ` Peter Staubach [this message]
2007-03-14 22:47                 ` Neil Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45F6CDA5.9020607@redhat.com \
    --to=staubach@redhat.com \
    --cc=SteveD@redhat.com \
    --cc=neilb@suse.de \
    --cc=nfs@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.