Setclientid / Definition of client

[J. Bruce Fields]

On Mon, Dec 04, 2006 at 11:35:23AM -0500, Trond Myklebust wrote:
> On Mon, 2006-12-04 at 11:25 -0500, J. Bruce Fields wrote:
> > Not necessarily--multiple users should be able to use the state
> > established by a setclientid performed by a single user.  But of course
> > if that single user goes away, then you're left with no way to
> > reestablish the state that was held under the clientid established by
> > that user.
> 
> Under what circumstances is that a problem? Normally, we just RENEW, and
> if that fails, we assume we will need to re-establish state from
> scratch.

I don't think we can guarantee the ability to hold onto that first
user's credentials for as long as some second user might be holding some
state.  So the problem would be something like:

	1. User 1 gets some state, and we establish clientid with
	   user 1's credentials.
	2. User 2 gets a lock on file foo.
	3. User 1 goes away, destroys any credentials.
	4. We're unable to renew the state, so lose user 2's lock.

Except, I'm wrong--the spec allows us to renew using user 2's
credentials, doesn't it?  We may lose the ability to invalidate our
previous state on a client reboot (but presumably letting it just expire
isn't a big problem in that case).

That does give the first user the ability to revoke any other user's
locks or opens, though.

What about a situation like this:

	1. User 1 opens a file, then closes it and goes away.  Noone
	else is holding any state, so we stop renewing.
	2. User 2 opens a file.

If 1 and 2 happen close enough together, then the server might still
consider the old client instance valid and reject user 2's setclientid.
Or is the server required to allow the setclientid if the old instance
doesn't hold any current state?  OK, it'd make sense to do that.

So, maybe that's a server-side bug.

> > Which is why by default the linux client is set up to use machine
> > credentials for this, which shouldn't ever go away.  So at least if
> > you're using a linux client, I don't think you should ever see the
> > rq_cred be different for two subsequent setclientid calls.
> 
> No. The Linux client tries to use the creds of the first person to open
> a file.

I'd forgotten about this change.

--b.