Bug in server's export -- List of security flavors

Bug in server's export -- List of security flavors

[Tom Haynes]

[tdh@adept tournament]> exportfs -rva
exporting 192.168.2.0/255.255.255.0:/home
exporting *:/
exportfs: could not open /var/lib/nfs/etab for locking
exportfs: can't lock /var/lib/nfs/etab for writing
[tdh@adept tournament]> more /etc/exports
/ *(sync)
/home 
192.168.2.0/255.255.255.0(rw,async,no_subtree_check,insecure,no_root_squash)
[tdh@adept tournament]> uname -a
Linux adept.internal.excfb.com 2.6.29.4-167.fc11.i586 #1 SMP Wed May 27 
17:14:37 EDT 2009 i686 i686 i386 GNU/Linux

So, adept:/home is exported in a fairly typical way that I've had going for
the past 3 years.

[root@witch ~]> mount -o vers=3 adept:/home /mnt
nfs mount: security mode does not match the server exporting adept:/home

The server is not sending any authentication flavors:

MOUNT:----- NFS MOUNT -----
MOUNT:
MOUNT:Proc = 1 (Add mount entry)
MOUNT:Status = 0 (OK)
MOUNT:File handle = [DADF]
MOUNT: 01000700010005000000000053CF6DE4FF1C4572BB2950392EB6993C
MOUNT:Authentication flavor =
MOUNT:

And yet this mount will work from a Linux box:

root@slayer:~# uname -a
Linux slayer 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 19:49:51 UTC 
2009 i686 GNU/Linux
root@slayer:~# mount -o vers=3 adept:/home /mnt

I'm guessing that the Linux client is ignoring the list and trying the 
default AUTH_SYS anyway. Is that
also a bug on the client, using a flavor not advertised by the server?

Re: Bug in server's export -- List of security flavors

[J. Bruce Fields]

On Thu, Jul 16, 2009 at 11:58:52AM -0500, Tom Haynes wrote:
> [tdh@adept tournament]> exportfs -rva
> exporting 192.168.2.0/255.255.255.0:/home
> exporting *:/
> exportfs: could not open /var/lib/nfs/etab for locking
> exportfs: can't lock /var/lib/nfs/etab for writing
> [tdh@adept tournament]> more /etc/exports
> / *(sync)
> /home  
> 192.168.2.0/255.255.255.0(rw,async,no_subtree_check,insecure,no_root_squash)
> [tdh@adept tournament]> uname -a
> Linux adept.internal.excfb.com 2.6.29.4-167.fc11.i586 #1 SMP Wed May 27  
> 17:14:37 EDT 2009 i686 i686 i386 GNU/Linux
>
> So, adept:/home is exported in a fairly typical way that I've had going for
> the past 3 years.
>
> [root@witch ~]> mount -o vers=3 adept:/home /mnt
> nfs mount: security mode does not match the server exporting adept:/home
>
> The server is not sending any authentication flavors:
>
> MOUNT:----- NFS MOUNT -----
> MOUNT:
> MOUNT:Proc = 1 (Add mount entry)
> MOUNT:Status = 0 (OK)
> MOUNT:File handle = [DADF]
> MOUNT: 01000700010005000000000053CF6DE4FF1C4572BB2950392EB6993C
> MOUNT:Authentication flavor =
> MOUNT:
>
> And yet this mount will work from a Linux box:
>
> root@slayer:~# uname -a
> Linux slayer 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 19:49:51 UTC  
> 2009 i686 GNU/Linux
> root@slayer:~# mount -o vers=3 adept:/home /mnt
>
> I'm guessing that the Linux client is ignoring the list and trying the  
> default AUTH_SYS anyway. Is that
> also a bug on the client, using a flavor not advertised by the server?

I don't see how it could be a problem for the client to try an
unadvertised flavor.  The server has to enforce the choice of flavor
anyway.

(Um, but that's pretty weird that the server's advertising an empty
list.  What's the nfs-utils version?)

--b.

Re: Bug in server's export -- List of security flavors

[Tom Haynes]

J. Bruce Fields wrote:
> I don't see how it could be a problem for the client to try an
> unadvertised flavor.  The server has to enforce the choice of flavor
> anyway.
>   

Yes, the server needs to enforce it, but why is the client trying a 
flavor that the server
says it does not support?



> (Um, but that's pretty weird that the server's advertising an empty
> list.  What's the nfs-utils version?)
>
>   


[tdh@adept root]> yum list nfs-utils
Loaded plugins: dellsysidplugin2, fastestmirror, refresh-packagekit
updates/metalink                                                                                                                       
| 2.9 kB     00:00
updates                                                                                                                                
| 4.4 kB     00:00
Installed Packages
nfs-utils.i586                                                            
1:1.1.5-6.fc11                                                             
installed

Re: Bug in server's export -- List of security flavors

[J. Bruce Fields]

On Thu, Jul 16, 2009 at 02:25:29PM -0500, Tom Haynes wrote:
> J. Bruce Fields wrote:
>> I don't see how it could be a problem for the client to try an
>> unadvertised flavor.  The server has to enforce the choice of flavor
>> anyway.
>>   
>
> Yes, the server needs to enforce it, but why is the client trying a  
> flavor that the server
> says it does not support?

Could just be excessively persistent of optimistic.  (Or in this case
probably it just doesn't have any negotiation code, so it's simplest
just to try the one flavor that was specified on the mount; seems fair
to me.)

There's also cases where this could also happen just due to bad timing:
maybe the export got changed in the middle.  If only for that reason, I
don't think we could forbid a client from doing this.

>> (Um, but that's pretty weird that the server's advertising an empty
>> list.  What's the nfs-utils version?)
>>
>>   
>
>
> [tdh@adept root]> yum list nfs-utils
> Loaded plugins: dellsysidplugin2, fastestmirror, refresh-packagekit
> updates/metalink                                                          
>                                                              | 2.9 kB     
> 00:00
> updates                                                                   
>                                                              | 4.4 kB     
> 00:00
> Installed Packages
> nfs-utils.i586                                                            
> 1:1.1.5-6.fc11                                                            
>  installed

Thanks!

Hm.  So this change of mine:

	603017f2c1587d760e2649b889b581ca267ffee7 "Determine supported
	pseudoflavors from export"

is probably at fault.  I guess we need to figure out why it's producing
a zero-length array.

--b.

Re: Bug in server's export -- List of security flavors

[Tom Haynes]

support/nfs/exports.c

505                 if (strcmp(opt, "ro") == 0)
506                         setflags(NFSEXP_READONLY, active, ep);
507                 else if (strcmp(opt, "rw") == 0)
508                         clearflags(NFSEXP_READONLY, active, ep);
...
624                 } else if (strncmp(opt, "sec=", 4) == 0) {
625                         active = parse_flavors(opt+4, ep);

If you find a 'sec=' you go ahead and set it in the e_secinfo array.

But if you encounter a rw or ro before you encounter a 'sec=', you do
not set a flavor in the e_secinfo array.

What we do is if we encounter the 'rw' or 'ro' before the 'sec=', then
it defaults to being a AUTH_SYS flavor. If we encounter it after, then
we know which flavor to set it as.

Of course, we have to account for what happens if we have the following:
share -F nfs -o rw,sec=sys,ro /foo

Because we can't have both a rw and ro export.

Re: Bug in server's export -- List of security flavors

[J. Bruce Fields]

On Thu, Jul 16, 2009 at 03:13:52PM -0500, Tom Haynes wrote:
> support/nfs/exports.c
>
> 505                 if (strcmp(opt, "ro") == 0)
> 506                         setflags(NFSEXP_READONLY, active, ep);
> 507                 else if (strcmp(opt, "rw") == 0)
> 508                         clearflags(NFSEXP_READONLY, active, ep);
> ...
> 624                 } else if (strncmp(opt, "sec=", 4) == 0) {
> 625                         active = parse_flavors(opt+4, ep);
>
> If you find a 'sec=' you go ahead and set it in the e_secinfo array.
>
> But if you encounter a rw or ro before you encounter a 'sec=', you do
> not set a flavor in the e_secinfo array.

Yep, thanks!

> What we do is if we encounter the 'rw' or 'ro' before the 'sec=', then
> it defaults to being a AUTH_SYS flavor. If we encounter it after, then
> we know which flavor to set it as.

I think at least in our case it's easier just to check for the no-sec=
case at the time we construct the MOUNT response and put that default
case there.  Patch follows.

>
> Of course, we have to account for what happens if we have the following:
> share -F nfs -o rw,sec=sys,ro /foo
>
> Because we can't have both a rw and ro export.

I believe the current linux nfs-utils code allows conflicting export
options, and lets the last option specified win.

Also, if the first sec= option comes at the middle or end of the list,
we take the initial export options as applying to that list of flavors,
and don't assume the first options were meant to apply to a default
(sec=sys) case.  So:

	ro,sec=krb5,rw

is the same as

	sec=krb5,ro,rw

is the same as

	sec=krb5,rw

and gets you an export accessible only with krb5.

and if you meant those first options to apply to sec=sys, that needs to
be explicitly stated:

	sec=sys,ro,sec=krb5,rw

I don't know if that's consistent with Solaris or not.

My guess is that if someone appends a "sec=krb5" option at the end of a
long list of options, then what we do is probably what they intended,
since previous to this, order didn't really matter to export options
(except in the odd case of conflicting options).  So I think it's less
suprising behavior in simple cases.  But it may make the behavior in
general more complicated to describe.

--b.

commit ccee90d1039b2ba81b497ac6374addc627887da3
Author: J. Bruce Fields <bfields@citi.umich.edu>
Date:   Tue Jul 21 19:30:04 2009 -0400

    Don't give client an empty flavor list
    
    In the absence of an explicit sec= option on an export, rpc.mountd is
    returning a zero-length flavor list to clients in the MOUNT results.
    
    The linux client doesn't seem to mind, but the Solaris client
    (reasonably enough) is giving up; the symptom is a "security mode does
    not match" error on mount.
    
    We could modify the export-parsing code to ensure the secinfo array is
    nonzero.  But I think it's slightly simpler to handle this default case
    in the implementation of the MOUNT call.  This is more-or-less the same
    thing the kernel does when mountd passes it an export without any
    security flavors specified.
    
    Thanks to Tom Haynes for bug report and diagnosis.
    
    Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>

diff --git a/utils/mountd/mountd.c b/utils/mountd/mountd.c
index b59f939..888fd8c 100644
--- a/utils/mountd/mountd.c
+++ b/utils/mountd/mountd.c
@@ -359,6 +359,11 @@ static void set_authflavors(struct mountres3_ok *ok, nfs_export *exp)
 		flavors[i] = s->flav->fnum;
 		i++;
 	}
+	if (i == 0) {
+		/* default when there is no sec= option: */
+		i = 1;
+		flavors[0] = AUTH_UNIX;
+	}
 	ok->auth_flavors.auth_flavors_val = flavors;
 	ok->auth_flavors.auth_flavors_len = i;
 }

[PATCH] Don't give client an empty flavor list

[J. Bruce Fields]

From: J. Bruce Fields <bfields@citi.umich.edu>

In the absence of an explicit sec= option on an export, rpc.mountd is
returning a zero-length flavor list to clients in the MOUNT results.

The linux client doesn't seem to mind, but the Solaris client
(reasonably enough) is giving up; the symptom is a "security mode does
not match" error on mount.

We could modify the export-parsing code to ensure the secinfo array is
nonzero.  But I think it's slightly simpler to handle this default case
in the implementation of the MOUNT call.  This is more-or-less the same
thing the kernel does when mountd passes it an export without any
security flavors specified.

Thanks to Tom Haynes for bug report and diagnosis.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
 utils/mountd/mountd.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/utils/mountd/mountd.c b/utils/mountd/mountd.c
index b59f939..888fd8c 100644
--- a/utils/mountd/mountd.c
+++ b/utils/mountd/mountd.c
@@ -359,6 +359,11 @@ static void set_authflavors(struct mountres3_ok *ok, nfs_export *exp)
 		flavors[i] = s->flav->fnum;
 		i++;
 	}
+	if (i == 0) {
+		/* default when there is no sec= option: */
+		i = 1;
+		flavors[0] = AUTH_UNIX;
+	}
 	ok->auth_flavors.auth_flavors_val = flavors;
 	ok->auth_flavors.auth_flavors_len = i;
 }
-- 
1.6.0.4

Re: Bug in server's export -- List of security flavors

[Chuck Lever]

On Jul 16, 2009, at 3:25 PM, Tom Haynes wrote:
> J. Bruce Fields wrote:
>> I don't see how it could be a problem for the client to try an
>> unadvertised flavor.  The server has to enforce the choice of flavor
>> anyway.
>
> Yes, the server needs to enforce it, but why is the client trying a  
> flavor that the server
> says it does not support?

If this mount request is generated by the kernel (kernels after 2.6.23  
or so) and not by the mount command, the kernel's mount client does  
not have support for reading the authlist returned by the server.  I  
sent patches to Trond for 2.6.32 to address this.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com