Subject: RE: setclientid

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 15 Jul 2002 07:31:00 -0700

Peter Astrand wrote:
Quoting (I presume) [email-masked] who wrote:
> > I've just taken a stab at implementing this and have run into the following.
> > 
> > How is the server supposed to distinguish between a client doing a retry
> > of setclientid and different clients doing a setclientid with the same
> > "id". (The latter is supposed to get the response NFS4ERR_CLID_INUSE
> > whereas the former should get an NFS_OK with the clientid?)
> > 
> > It looks like the Univ. of Michigan server differentiates between these
> > two cases by looking at the source IP# (not in the callback info in the
> > request, but from the transport layer). Does this sound right, or should
> > it use the callback net address info or ??

> I asked a similiar question a few months ago, see 
> http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/2002/0085.html. 

I just looked at that and I didn't understand Spencer's response.  Maybe
I'm missing some context.

> I have a general feeling of that SETCLIENTID is more broken than it has to
> be. 

Not clear here if you mean the definition in the spec or the UMich 
implementation (or both).

> I think it's strange and awkward that CLID_INUSE cannot be triggered
> from one machine, even though it's possible to run several user-level
> clients on the same host. Using the source IP from the transport layer is
> also strange. 

Yes it's strange but I don't think it's necessarily wrong.  My understanding
is that the spec allows but doesn't require this kind of implementation.

The basic idea of SETCLIENTID is that the client somehow picks a 
unique value of what the spec calls an nfs_client_id4 (and what I
think should be called client_name but is normally referred to as
that-client-id-that-the-client-specifies-not-the-64-bit-thing-but-
the-other-one).  When the values are unique everything works fine,
but there has to be provision for detecting misconfiguration when
they are not.  In normal environments if clients are implemented
to throw lots of uniquifying stuff into the client-name, then this
won't happen, but it is conceivable that it will.  

I don't see that an ideal solution to this problem is possible.  You
have to ultimately depend on the clients getting this one thing right.
In that context, deciding that if you get the same client-name from 
two different IP addresses, you are going to figure that that is a
mistake, doesn't seem unreasonable to me.  My code doesn't do that
right now, but doesn't seem wrong to me, even though there is 
something strange about it (it crosses levels of abstraction in a
way that seems hacky).

If you have mutliple user level clients on the same machine and 
they use the same client-names and the same principals then you
have no recourse.  I think you are limited in what you can do to
check up the client.  Some sorts of misconfiguration will just
not be detectable.

> Doesn't this mean that if the client is changing IP and then
> does a new SETCLIENTID, then the server will respond with
> NFS4ERR_CLID_INUSE?

Yes it does mean that.  The question is whether that is a requirement.
I think we need to decide if it is.

> Is it really necessary for the server to store the client adress as a part 
> of the client information? Too me, it seems sufficient that the server 
> stores nfs_client_id and principal. CLID_INUSE could be reserved only for 
> the case where the principal does not match. Or have I forgotten 
> something?

I think your solution doesn't account for the case of auth-sys, which
while deprecated, will continue to exist in some environments.  In those
environments, there won't be any real principal to match and so there 
is a choice of having no check for misconfiguration (multiple clients
with the same client id), if you don't check on IP address.

> Btw, if the client sends a CLIENTID with the same nfs_client_id but a 
> different cb_client4, should the server then update the callback 
> information? I suppose this will be necessary if the client wants to 
> change IP without having to release all state. 

This is Issue 175 on the issues list. 

There are a number of inter-related (in some cases potentially inter-
related) issues that relate to SETCLIENTID.  I'm going through the issues
list now as a kind of triage (although I have more than three categories)
as part helping along the process of getting to a completed spec by early 
August.  One of the categories is items that require some discussion within
the group to determine the proper constraints on the spec choices.  The
SETCLIENTID stuff seems to fall (or you have just pushed it) into that
category.

---

From: Peter Astrand <[email-masked]>
Date: Mon, 15 Jul 2002 20:20:34 +0200 (CEST)

> implementation (or both).

The implementation, primarily. 

> have to ultimately depend on the clients getting this one thing right.

Yes, you are right. 

> I think we need to decide if it is.

I would prefer that this is not a requirement. 

If it is, how are you supposed to be able to change IP at all on your 
client? Is the client supposed to wait for the server release of clientid 
(described in section 8.1.2)? This may, as I understand it, take a long 
time or not happen at all. 

Btw, is it a good idea to use the FQDN hostname as nfs_client_id.id?

> with the same client id), if you don't check on IP address.

Would it be possible to use the machinename from auth-sys? This seems like 
a better strategi than the transport IP, since it would at least allow 
changing IP. 

Anyway, this is maybe 4.1 stuff. 

> SETCLIENTID stuff seems to fall (or you have just pushed it) into that

Ok. I also think that getting the spec out is top prio. 

Btw, is anyone maintaining a 4.1 TODO/wishlist? I can do that, otherwise. 
I have some things to put on the list already :-)

-- 
/Peter Åstrand <[email-masked]>