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

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

[Steve Dickson]

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2: patch-06.dif --]
[-- Type: text/x-patch, Size: 910 bytes --]

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)
    
    Signed-off-by: Steve Dickson <steved@redhat.com>

diff --git a/utils/mount/nfsmount.c b/utils/mount/nfsmount.c
index d437036..7759260 100644
--- a/utils/mount/nfsmount.c
+++ b/utils/mount/nfsmount.c
@@ -1093,12 +1093,14 @@ nfsmount(const char *spec, const char *node, int *flags,
 
 		flavor = mountres->auth_flavors.auth_flavors_val;
 		while (--i >= 0) {
-			if (flavor[i] == data.pseudoflavor)
-				yum = 1;
 #ifdef NFS_MOUNT_DEBUG
-			printf("auth flavor %d: %d\n",
-				i, flavor[i]);
+			printf("auth flavor[%d] %d\n", i, flavor[i]);
 #endif
+			if (flavor[i] == data.pseudoflavor ||
+				flavor[i] == AUTH_NONE) {
+				yum = 1;
+				break;
+			}
 		}
 		if (!yum) {
 			fprintf(stderr,

[-- Attachment #3: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
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

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Neil Brown]

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

>     
>     Signed-off-by: Steve Dickson <steved@redhat.com>
> 
> diff --git a/utils/mount/nfsmount.c b/utils/mount/nfsmount.c
> index d437036..7759260 100644
> --- a/utils/mount/nfsmount.c
> +++ b/utils/mount/nfsmount.c
> @@ -1093,12 +1093,14 @@ nfsmount(const char *spec, const char *node, int *flags,
>  
>  		flavor = mountres->auth_flavors.auth_flavors_val;
>  		while (--i >= 0) {
> -			if (flavor[i] == data.pseudoflavor)
> -				yum = 1;
>  #ifdef NFS_MOUNT_DEBUG
> -			printf("auth flavor %d: %d\n",
> -				i, flavor[i]);
> +			printf("auth flavor[%d] %d\n", i, flavor[i]);
>  #endif
> +			if (flavor[i] == data.pseudoflavor ||
> +				flavor[i] == AUTH_NONE) {
> +				yum = 1;
> +				break;
> +			}

You are testing if flavor[i] == AUTH_NONE, which doesn't make sense to
me....

NeilBrown

-------------------------------------------------------------------------
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

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

[Peter Staubach]

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.

>>     
>>     Signed-off-by: Steve Dickson <steved@redhat.com>
>>
>> diff --git a/utils/mount/nfsmount.c b/utils/mount/nfsmount.c
>> index d437036..7759260 100644
>> --- a/utils/mount/nfsmount.c
>> +++ b/utils/mount/nfsmount.c
>> @@ -1093,12 +1093,14 @@ nfsmount(const char *spec, const char *node, int *flags,
>>  
>>  		flavor = mountres->auth_flavors.auth_flavors_val;
>>  		while (--i >= 0) {
>> -			if (flavor[i] == data.pseudoflavor)
>> -				yum = 1;
>>  #ifdef NFS_MOUNT_DEBUG
>> -			printf("auth flavor %d: %d\n",
>> -				i, flavor[i]);
>> +			printf("auth flavor[%d] %d\n", i, flavor[i]);
>>  #endif
>> +			if (flavor[i] == data.pseudoflavor ||
>> +				flavor[i] == AUTH_NONE) {
>> +				yum = 1;
>> +				break;
>> +			}
>>     
>
> You are testing if flavor[i] == AUTH_NONE, which doesn't make sense to
> me....

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.

       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

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

[Neil Brown]

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?

Thanks,
NeilBrown

-------------------------------------------------------------------------
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

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

[Peter Staubach]

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

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

[Neil Brown]

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?

NeilBrown

--- a/utils/mount/nfsmount.c
+++ b/utils/mount/nfsmount.c
@@ -638,7 +638,9 @@ parse_options(char *old_opts, struct nfs_mount_data *data,
 				if (nfs_mount_version < 5) {
 					printf(_("Warning: ignoring sec=%s option\n"), secflavor);
 					continue;
-				} else if (!strcmp(secflavor, "sys"))
+				} else if (!strcmp(secflavor, "none"))
+					data->pseudoflavor = AUTH_NONE;
+				else if (!strcmp(secflavor, "sys"))
 					data->pseudoflavor = AUTH_SYS;
 				else if (!strcmp(secflavor, "krb5"))
 					data->pseudoflavor = AUTH_GSS_KRB5;

-------------------------------------------------------------------------
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

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

[Peter Staubach]

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.

With this change, autofs would not be able correctly handle mounting
this server via /net.  It should be able to, especially since the
server will accept _any_ flavor coming from the client.

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?

    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

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

[Neil Brown]

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.

> 
> 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.

NeilBrown

diff --git a/utils/mount/nfsmount.c b/utils/mount/nfsmount.c
index f21c81c..eaf70f5 100644
--- a/utils/mount/nfsmount.c
+++ b/utils/mount/nfsmount.c
@@ -902,7 +902,7 @@ nfsmount(const char *spec, const char *node, int *flags,
 #if NFS_MOUNT_VERSION >= 2
 	data.namlen	= NAME_MAX;
 #endif
-	data.pseudoflavor = AUTH_SYS;
+	data.pseudoflavor = -1; /* accept AUTH_SYS or AUTH_NONE */
 
 	bg = 0;
 	retry = 10000;		/* 10000 minutes ~ 1 week */
@@ -1090,6 +1090,14 @@ nfsmount(const char *spec, const char *node, int *flags,
 
 		flavor = mountres->auth_flavors.auth_flavors_val;
 		while (--i >= 0) {
+			/* If no flavour requests, use any simple
+			 * flavour that is offered.
+			 */
+			if (data.pseudoflavor == -1 &&
+			    (flavor[i] == AUTH_SYS ||
+			     flavor[i] == AUTH_NONE))
+				data.pseudoflavor = flavor[i];
+
 			if (flavor[i] == data.pseudoflavor)
 				yum = 1;
 #ifdef NFS_MOUNT_DEBUG

-------------------------------------------------------------------------
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

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

[Peter Staubach]

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

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

[Neil Brown]

On Tuesday March 13, staubach@redhat.com wrote:
> 
> The small update to the patch is to add the line:
> 
>     data.flags |= NFS_MOUNT_SECFLAVOUR;
> 
> after setting data.pseudoflavor to flavor[i].

Thanks... That implies that I don't need the (rather ugly) -1 value to
say "nothing requested".  I can just test this flag and set
data.pseudoflavor to flavor[i] if it isn't set.

Thanks.


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

Not me, know...

NeilBrown

-------------------------------------------------------------------------
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