All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Jeff Layton <jlayton@redhat.com>,
	linux-nfs@vger.kernel.org, nfsv4@linux-nfs.org
Subject: Re: [PATCH 3/5] nfs-utils: query for remote port using rpcbind instead of getaddrinfo
Date: Tue, 7 Apr 2009 12:20:05 -0400	[thread overview]
Message-ID: <20090407162005.GC24157@fieldses.org> (raw)
In-Reply-To: <41F98279-F000-4C1C-8E44-3568C89FC2BD@oracle.com>

On Tue, Apr 07, 2009 at 12:02:46PM -0400, Chuck Lever wrote:
> 
> On Apr 7, 2009, at 11:25 AM, Jeff Layton wrote:
> 
> > We already have the server's address from the upcall, so we don't  
> > really
> > need to look it up again, and querying the local services DB for the
> > port that the remote server is listening on is just plain wrong.
> >
> > Use rpcbind to set the port for the program and version that we were
> > given in the upcall. The exception here is NFSv4. Since NFSv4 mounts
> > are supposed to use a well-defined port then skip the rpcbind query
> > for that and just set the port to the standard one (2049).
> >
> > Signed-off-by: Jeff Layton <jlayton@redhat.com>
> > ---
> > utils/gssd/gssd_proc.c |  126 ++++++++++++++++++++++++++++ 
> > +-------------------
> > 1 files changed, 76 insertions(+), 50 deletions(-)
> >
> > diff --git a/utils/gssd/gssd_proc.c b/utils/gssd/gssd_proc.c
> > index 9d3712b..1571329 100644
> > --- a/utils/gssd/gssd_proc.c
> > +++ b/utils/gssd/gssd_proc.c
> > @@ -72,6 +72,7 @@
> > #include "gss_util.h"
> > #include "krb5_util.h"
> > #include "context.h"
> > +#include "nfsrpc.h"
> >
> > /*
> >  * pollarray:
> > @@ -541,6 +542,64 @@ out_err:
> > }
> >
> > /*
> > + * If the port isn't already set, do an rpcbind query to the remote  
> > server
> > + * using the program and version and get the port. Newer kernels  
> > send the
> > + * port in the upcall, so this is really only for compatibility  
> > with older
> > + * ones.
> > + */
> > +static int
> > +populate_port(struct sockaddr *sa, const socklen_t salen,
> > +	      const rpcprog_t program, const rpcvers_t version,
> > +	      const unsigned short protocol)
> > +{
> > +	struct sockaddr_in	*s4 = (struct sockaddr_in *) sa;
> > +	unsigned short		port;
> > +
> > +	/*
> > +	 * Newer kernels send the port in the upcall. If we already have
> > +	 * the port, there's no need to look it up.
> > +	 */
> > +	switch (sa->sa_family) {
> > +	case AF_INET:
> > +		if (s4->sin_port != 0) {
> > +			printerr(2, "DEBUG: port already set to %d\n",
> > +				 ntohs(s4->sin_port));
> > +			return 1;
> > +		}
> > +		break;
> > +	default:
> > +		printerr(0, "ERROR: unsupported address family %d\n",
> > +			    sa->sa_family);
> > +		return 0;
> > +	}
> > +
> > +	/* Use standard NFS port for NFSv4 */
> > +	if (program == 100003 && version == 4) {
> > +		port = 2049;
> > +		goto set_port;
> > +	}
> 
> I think this patch set looks pretty reasonable.  Here's my one  
> remaining quibble.
> 
> You can specify "port=" for nfs4 mounts, in which case we want to use  
> that value here, too, I think.  It would be simpler overall if the  
> kernel always passed up the value it is using for port= on this mount  
> point.
> 
> The rules for how the kernel uses the port= setting are:
> 
>   + if port= is not specified on NFSv2/v3, port= setting is zero
>   + if port= is not specified on NFSv4, port= setting is 2049
> 
> Then, when setting up a tranport:
> 
>   + if the port= setting is zero, do an rpcbind
>   + if the port= setting is not zero, use that value
> 
> If the kernel always passes the port= setting to gssd, then it can  
> follow the "if port value is zero, rpcbind; otherwise use port value  
> as is" rule, and be sure to get correct NFSv4 behavior, even without  
> the special case you added for NFSv4.

In recent kernels that information is in the "info" file for the given
client in rpc_pipefs.  Kevin and Olga have patches to support that in
gssd, if they aren't already in upstream nfs-utils.

And of course it's important to use that when it's available, to avoid
unnecessary rpcbind calls (in a pure nfsv4 environment the only firewall
hole you should have to poke is for the nfsv4 port), to respect the
port= mount option for people running a v4 server on an alternate port,
and for authenticating the callback channel (which won't normally be to
port 2049, and won't (I assume) normally be registered with the
portmapper).

--b.

  reply	other threads:[~2009-04-07 16:20 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-07 15:25 [PATCH 0/5] nfs-utils: convert gssd to TI-RPC and add IPv6 support (try #4) Jeff Layton
2009-04-07 15:25 ` [PATCH 1/5] nfs-utils: make getnameinfo() required for --enable-gss Jeff Layton
2009-04-07 15:25 ` [PATCH 2/5] nfs-utils: store the address given in the upcall for later use Jeff Layton
2009-04-07 15:25 ` [PATCH 3/5] nfs-utils: query for remote port using rpcbind instead of getaddrinfo Jeff Layton
2009-04-07 16:02   ` Chuck Lever
2009-04-07 16:20     ` J. Bruce Fields [this message]
2009-04-07 16:29       ` Chuck Lever
2009-04-07 16:32         ` J. Bruce Fields
2009-04-07 16:34           ` Chuck Lever
2009-04-07 17:00             ` Jeff Layton
2009-04-07 17:12               ` Chuck Lever
2009-04-07 16:27     ` Tom Talpey
2009-04-07 16:32       ` Chuck Lever
2009-04-07 17:11       ` Jeff Layton
     [not found]         ` <20090407131151.69203e5e-RtJpwOs3+0O+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2009-04-07 19:43           ` Tom Talpey
2009-04-07 19:53             ` Jeff Layton
2009-04-07 20:01               ` Tom Talpey
     [not found]                 ` <49dbb129.02045a0a.023b.6bc7-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-04-07 20:30                   ` Jeff Layton
2009-04-07 23:16                     ` J. Bruce Fields
2009-04-07 23:27                       ` Jeff Layton
2009-04-07 23:14             ` J. Bruce Fields
2009-04-07 23:37               ` Jeff Layton
2009-04-08 19:32               ` Chuck Lever
2009-04-09 16:19                 ` J. Bruce Fields
2009-04-09 17:34                   ` Chuck Lever
2009-04-07 15:25 ` [PATCH 4/5] nfs-utils: switch gssd to use standard function for getting an RPC client Jeff Layton
2009-04-07 15:25 ` [PATCH 5/5] nfs-utils: add IPv6 code to gssd Jeff Layton
2009-04-15 16:02 ` [PATCH 0/5] nfs-utils: convert gssd to TI-RPC and add IPv6 support (try #4) Steve Dickson

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=20090407162005.GC24157@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=jlayton@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=nfsv4@linux-nfs.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.