Linux NFS development
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Rick Macklem <rmacklem@uoguelph.ca>
Cc: Nikolaus Rath <Nikolaus@rath.org>,
	linux-nfs@vger.kernel.org, nfsv4@ietf.org
Subject: Re: [nfsv4] NFS4 over VPN hangs when connecting > 2 clients
Date: Mon, 19 Mar 2012 13:36:56 -0400	[thread overview]
Message-ID: <20120319173656.GA23670@fieldses.org> (raw)
In-Reply-To: <1802632483.1230802.1332176807484.JavaMail.root@erie.cs.uoguelph.ca>

On Mon, Mar 19, 2012 at 01:06:47PM -0400, Rick Macklem wrote:
> I wrote:
> > J. Bruce Fields wrote:
> > > On Mon, Mar 12, 2012 at 05:27:08PM -0400, J. Bruce Fields wrote:
> > > > On Mon, Mar 12, 2012 at 05:14:16PM -0400, Chuck Lever wrote:
> > > > > IMO, the server should do a comparison of the nfs_client_id4
> > > > > strings,
> > > > > and nothing else.
> > > >
> > > > We're supposed to return CLID_INUSE when we see a setclientid from
> > > > a
> > > > "different" client using the same string, to keep clients from
> > > > doing
> > > > mischief with other clients' state (either maliciously or, as in
> > > > this
> > > > case, accidentally).
> > > >
> > > > "Different" here is defined as "not having the same principal". I
> > > > know
> > > > what that means in the krb5 case, but I'm less certain in the
> > > > auth_sys
> > > > case.
> > >
> > > Cc'ing the ietf list. Is it reasonable for a server to expect
> > > setclientid's to come from the same client IP address at least in
> > > the
> > > auth_sys case, or could that break multi-homed clients?
> > >
> > I think that even a dhcp lease renewal might result in a different
> > client
> > IP, if the client has been partitioned from the dhcp server for a
> > while.

Yeah, but by that point the client's v4 lease is probably expired anyway
so the client's not likely to be bothered by the NFS4ERR_INUSE.

> > I'm not convinced that different client IP# implies different client.
> > (Even "same ip# implies same client" might not be true, if the dhcp
> > server assigned the IP# to another machine while the client was
> > partitioned
> > from the dhcp server, I think? I haven't looked at current dhcp
> > implementations, but it seems conceivable to me.)
> > 
> Oh, and what about the case of 2 clients that are sitting behind
> the same NAT gateway? (I think they'd both be seen as having the
> client host ip# of the gateway, but with different TCP connections
> on different client port#s.)

Well, sure, but all I'm proposing here is returning NFS4ERR_INUSE in the
case where we get setclientid's with the same client-provided id.
There'd be no change of behavior in the case of multiple clients sharing
an IP (which is fine, of course).

> > For AUTH_SYS, all the FreeBSD server does is expect the same uid#.

Yeah, but that's probably usually the same between clients.

--b.

  reply	other threads:[~2012-03-19 17:36 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-11  1:34 NFS4 over VPN hangs when connecting > 2 clients Nikolaus Rath
2012-03-12 16:20 ` Nikolaus Rath
2012-03-12 19:31   ` J. Bruce Fields
2012-03-12 19:45     ` Nikolaus Rath
2012-03-12 20:15       ` J. Bruce Fields
2012-03-12 20:30         ` Nikolaus Rath
2012-03-12 20:42           ` J. Bruce Fields
2012-03-12 20:49             ` Chuck Lever
2012-03-12 21:04               ` J. Bruce Fields
2012-03-12 21:14                 ` Chuck Lever
2012-03-12 21:27                   ` J. Bruce Fields
2012-03-19 16:28                     ` J. Bruce Fields
2012-03-19 16:44                       ` [nfsv4] " Rick Macklem
2012-03-19 17:06                         ` Rick Macklem
2012-03-19 17:36                           ` J. Bruce Fields [this message]
2012-03-19 17:47                             ` Chuck Lever
2012-03-19 18:24                               ` Myklebust, Trond
2012-03-19 18:27                               ` J. Bruce Fields
2012-03-19 18:29                                 ` Chuck Lever
2012-03-19 18:39                                   ` J. Bruce Fields
2012-03-19 18:42                                     ` Chuck Lever
2012-03-19 18:54                                       ` J. Bruce Fields
2012-03-19 19:00                                         ` Chuck Lever
2012-03-19 19:08                                           ` J. Bruce Fields
2012-03-19 18:43                                     ` Nikolaus Rath
2012-03-19 22:25                                       ` Rick Macklem
2012-03-20 13:29                                         ` Nikolaus Rath
2012-03-20 13:55                                           ` Myklebust, Trond
2012-03-20 14:36                                             ` Nikolaus Rath
2012-03-20 16:49                                               ` Myklebust, Trond
2012-03-20 14:01                                           ` Chuck Lever
2012-03-20 14:38                                             ` Nikolaus Rath
2012-03-20 15:53                                               ` Chuck Lever
2012-03-19 18:51                                     ` Nikolaus Rath
2012-03-19 18:56                                       ` J. Bruce Fields
2012-03-19 22:31                               ` Rick Macklem
2012-03-19 18:26                       ` Myklebust, Trond
2012-03-12 21:24         ` Nikolaus Rath
2012-03-12 21:27           ` Chuck Lever
2012-03-12 21:38             ` Nikolaus Rath
2012-03-12 21:46               ` Chuck Lever
2012-03-12 21:54                 ` Chuck Lever
2012-03-12 21:54                 ` Nikolaus Rath
2012-03-12 21:57                 ` Myklebust, Trond
2012-03-13 13:23                   ` Nikolaus Rath
2012-03-13 14:50                     ` Myklebust, Trond

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=20120319173656.GA23670@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=Nikolaus@rath.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=nfsv4@ietf.org \
    --cc=rmacklem@uoguelph.ca \
    /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