Subject: [nfsv4] yet more on NFS4ERR_CLID_INUSE

From: [email-masked]
Date: Tue, 14 Dec 2004 11:48:27 -0500 (EST)

I've put responses to two messages in here. Hope that's ok.

> Why wouldn't the server just return NFS4ERR_STALE_CLIENTID when client A
> presents its clientid? The correct response from client A is then simply
> to issue a new SETCLIENTID.

To do this, the server would have to keep the old Client A's record when the
new one is issued to the nasty client, marked "return NFS4ERR_STALE_CLIENTID"
for this one. (Normally, NFS4ERR_STALE_CLIENTID is recognized by a field in
the clientid that only changes when the server reboots, at least for my server.)
This seems like a much more complex "special case" handling than what I
originally proposed. And which I think you've agreed with, as follows:

> Then don't export anything as AUTH_SYS to client B 'cos AUTH_SYS is only
> meant to be used for clients that you can trust 100% not to do nasty
> things (like set mandatory locks on all the files, spoof other people's
> identities, close all their files,...).

Yes, and I think that was what I was trying to say in the initial message.
ie. Since I'll only allow clients I "trust 100%" (or at least 99%:-) to
mount with AUTH_SYS, then the check for "same principal" either isn't
necessary at all or can be minimal. (Others didn't see AUTH_SYS as a
special case, although I do.)

> This is like saying that you can DOS Apache provided you have root
> access to the server that is running it...

I think we also agree here? I don't like the idea of comparing uids, since
[email-masked] becomes the same as
[email-masked] because it seems to make them all "root".

I'm not sure that water's any clearer yet, but its been fun sofar, rick
ps: If the client changes it's "idname" when it does the SetClientID with a
    different authentication mechanism, the NFS4ERR_CLID_INUSE no longer
    gets replied. I was just trying to avoid the client's needing to do that.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 14 Dec 2004 12:40:02 -0500

> originally proposed. And which I think you've agreed with, as follows:

Why? NFS4ERR_STALE_CLIENTID really just means that "I don't currently
recognize your clientid". It makes no promises that "I used to recognize
it".

   NFS4ERR_STALE_CLIENTID A clientid not recognized by the server was
                          used in a locking or SETCLIENTID_CONFIRM
                          request.

>     gets replied. I was just trying to avoid the client's needing to do that.

Instead of encoding the authentication mechanism, the client could
instead encode the principal it is using inside the client id string.

Cheers,
  Trond
-- 
Trond Myklebust <[email-masked]>