On Fri, Aug 21, 2009 at 02:16:08PM -0400, Chuck Lever wrote:
> I want to understand the server bug a little more. I glanced over RFC
> 2623 and didn't see anything specific.
>
> Is it the case that only Linux NFSD does this, or do other servers do
> it? In other words, is this a typical server response, and if so, is
> there a specific semantic attached to it?
>
> If no list is provided, should the client assume that only AUTH_NONE and
> AUTH_SYS are supported, or instead, perhaps that the client can try to
> use any flavor? In other words, if no list is provided, let the mount
> proceed no matter what was specified by sec= ?
I've sent the following to Steve to fix the server bug.
--b.
commit ceb3c96d68f47cf6a0c38ccd88b98c59c886e9fb
Author: J. Bruce Fields <bfields@xxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxx>
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;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
