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

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

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

[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

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.

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.

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.

Yep, thanks!

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.

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 <[email protected]>
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.

index b59f939..888fd8c 100644
@@ -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;
 }

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

From: J. Bruce Fields <[email protected]>

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.

---
 utils/mountd/mountd.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

index b59f939..888fd8c 100644
@@ -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