All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Steve Dickson <steved@redhat.com>
Cc: linux-nfs@vger.kernel.org, Tom Haynes <tdh@excfb.com>
Subject: [PATCH] Don't give client an empty flavor list
Date: Mon, 17 Aug 2009 13:33:56 -0400	[thread overview]
Message-ID: <20090817173356.GF27331@fieldses.org> (raw)
In-Reply-To: <20090722000955.GC20694@fieldses.org>

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


  reply	other threads:[~2009-08-17 17:33 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-16 16:58 Bug in server's export -- List of security flavors Tom Haynes
     [not found] ` <4A5F5C4C.3070308-8AdZ+HgO7noAvxtiuMwx3w@public.gmane.org>
2009-07-16 18:56   ` J. Bruce Fields
2009-07-16 19:25     ` Tom Haynes
     [not found]       ` <4A5F7EA9.9050309-8AdZ+HgO7noAvxtiuMwx3w@public.gmane.org>
2009-07-16 19:45         ` J. Bruce Fields
2009-07-16 20:13           ` Tom Haynes
     [not found]             ` <4A5F8A00.8000104-8AdZ+HgO7noAvxtiuMwx3w@public.gmane.org>
2009-07-22  0:09               ` J. Bruce Fields
2009-08-17 17:33                 ` J. Bruce Fields [this message]
2009-08-03 13:11         ` Chuck Lever

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=20090817173356.GF27331@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=steved@redhat.com \
    --cc=tdh@excfb.com \
    /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.