Linux NFS development
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox