All of lore.kernel.org
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: Steve Dickson <SteveD@redhat.com>
Cc: "Myklebust, Trond" <Trond.Myklebust@netapp.com>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Charles Edward Lever <chuck.lever@oracle.com>,
	"Linux NFS Mailing List" <linux-nfs@vger.kernel.org>
Subject: [PATCH - nfs-utils] gssd: always reply to rpc-pipe requests from kernel.
Date: Thu, 14 Nov 2013 12:07:11 +1100	[thread overview]
Message-ID: <20131114120711.4043a60f@notabene.brown> (raw)
In-Reply-To: <1384306012.15992.9.camel@leira.trondhjem.org>

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


Sometimes gssd will open a new rpc-pipe but never read requests from it
or reply to them.  This causes the kernel to wait forever for a reply.

In particular, if a filesystem is mounted by IP, and the IP has no
hostname recorded in /etc/hosts or DNS, then gssd will not listen to
requests and the mount will hang indefinitely.

The comment in process_clnt_dir() for the "fail_keep_client:" branch
suggests that it is for the case where we couldn't open some
subdirectories.  However it is currently also taken if reverse DNS
lookup fails (as well as some other lookup failures).  Those failures
should not be treated the same as failure-to-open directories.

So this patch causes a failure from read_service_info() to *not* be
reported by process_clnt_dir_files.  This ensures that insert_clnt_poll()
will be called and requests will be handled.

In handle_gssd_upcall, the current error path (taken when the mech is
not "krb5") does not reply to the upcall.  This is wrong.  A reply is
always appropriate.  The only replies which aren't treated as
transient errors are EACCES and EKEYEXPIRED, so we return the former.

If read_service_info() fails then ->servicename will be NULL which will
cause process_krb5_upcall() (quite reasonably) to become confused.  So
in that case we don't even try to process the up-call but just reply
with EACCES.

As clp->servicename==NULL is no longer treated as fatal, it is not
appropraite to use it to test if read_service_info() has been already
called on a client.  Instread test clp->prog.

Finally, the error path of read_service_info() will close 'fd' if it
isn't -1, so when we close it, we should set fd to -1.

Signed-off-by: NeilBrown <neilb@suse.de>

diff --git a/utils/gssd/gssd_proc.c b/utils/gssd/gssd_proc.c
index b48d1637cd36..58c2a282524f 100644
--- a/utils/gssd/gssd_proc.c
+++ b/utils/gssd/gssd_proc.c
@@ -256,6 +256,7 @@ read_service_info(char *info_file_name, char **servicename, char **servername,
 	if ((nbytes = read(fd, buf, INFOBUFLEN)) == -1)
 		goto fail;
 	close(fd);
+	fd = -1;
 	buf[nbytes] = '\0';
 
 	numfields = sscanf(buf,"RPC server: %127s\n"
@@ -403,11 +404,10 @@ process_clnt_dir_files(struct clnt_info * clp)
 		return -1;
 	snprintf(info_file_name, sizeof(info_file_name), "%s/info",
 			clp->dirname);
-	if ((clp->servicename == NULL) &&
-	     read_service_info(info_file_name, &clp->servicename,
-				&clp->servername, &clp->prog, &clp->vers,
-				&clp->protocol, (struct sockaddr *) &clp->addr))
-		return -1;
+	if (clp->prog == 0)
+		read_service_info(info_file_name, &clp->servicename,
+				  &clp->servername, &clp->prog, &clp->vers,
+				  &clp->protocol, (struct sockaddr *) &clp->addr);
 	return 0;
 }
 
@@ -1320,11 +1320,14 @@ handle_gssd_upcall(struct clnt_info *clp)
 		}
 	}
 
-	if (strcmp(mech, "krb5") == 0)
+	if (strcmp(mech, "krb5") == 0 && clp->servername)
 		process_krb5_upcall(clp, uid, clp->gssd_fd, target, service);
-	else
-		printerr(0, "WARNING: handle_gssd_upcall: "
-			    "received unknown gss mech '%s'\n", mech);
+	else {
+		if (clp->servername)
+			printerr(0, "WARNING: handle_gssd_upcall: "
+				 "received unknown gss mech '%s'\n", mech);
+		do_error_downcall(clp->gssd_fd, uid, -EACCES);
+	}
 
 out:
 	free(lbuf);

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  parent reply	other threads:[~2013-11-14  1:07 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-09 22:47 [PATCH] Adding the nfs4_secure_mounts bool Steve Dickson
2013-11-09 23:12 ` Myklebust, Trond
2013-11-10 22:31   ` Steve Dickson
2013-11-10 22:45     ` Myklebust, Trond
2013-11-11 13:00       ` Steve Dickson
2013-11-11 18:06   ` Steve Dickson
2013-11-11 18:25     ` Myklebust, Trond
2013-11-11 18:43       ` Steve Dickson
2013-11-11 18:53         ` Myklebust, Trond
2013-11-11 19:05           ` Steve Dickson
2013-11-11 19:21             ` Myklebust, Trond
2013-11-11 18:30     ` Chuck Lever
2013-11-11 18:59       ` Steve Dickson
2013-11-11 20:33         ` Chuck Lever
2013-11-11 21:13           ` Steve Dickson
2013-11-11 21:47             ` Chuck Lever
2013-11-11 23:00               ` Steve Dickson
2013-11-12 16:09                 ` Chuck Lever
2013-11-12 16:24                   ` Steve Dickson
2013-11-12 16:46                     ` Chuck Lever
2013-11-12 16:52                       ` Steve Dickson
2013-11-12 16:10                 ` J. Bruce Fields
2013-11-12  5:11           ` NeilBrown
2013-11-12  5:29             ` Myklebust, Trond
2013-11-12 16:16               ` J. Bruce Fields
2013-11-13  0:23                 ` NeilBrown
2013-11-13  0:30                   ` Myklebust, Trond
2013-11-13  1:13                     ` NeilBrown
2013-11-13  1:26                       ` Myklebust, Trond
2013-11-14  1:05                         ` NeilBrown
2013-11-14  1:07                         ` NeilBrown [this message]
2013-11-14 13:34                           ` [PATCH - nfs-utils] gssd: always reply to rpc-pipe requests from kernel Jeff Layton
2013-11-20 21:21                           ` Steve Dickson
2013-11-13  3:46                   ` [PATCH] Adding the nfs4_secure_mounts bool J. Bruce Fields
2013-11-13  4:15                     ` Myklebust, Trond
2013-11-14  1:10                       ` NeilBrown

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=20131114120711.4043a60f@notabene.brown \
    --to=neilb@suse.de \
    --cc=SteveD@redhat.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    /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.