Subject: [nfsv4] NFS4ERR_CLID_INUSE when SetClientID changes authentication mechanisms

From: [email-masked]
Date: Sat, 11 Dec 2004 16:13:40 -0500 (EST)

A problem has cropped up when a client does a umount/mount of the same
file system, switching between AUTH_SYS and RPCSEC_GSS using Krb5. My
server sees the SetClientID with a different principal (uid==0 vs
[email-masked]) and replies NFS4ERR_CLID_INUSE.

At first, I thought this made sense and it was a client side problem,
but now I'm thinking that maybe my server should be changed...

If the "principal name" is the GSSAPI one, ie:
[email-masked] (not root/host.domain@KRB5REALM)
then I think it would stay the same when switching between different
Mechanisms in RPCSEC_GSS. Is that right?

If so, then AUTH_SYS becomes a special case, since it doen't really have
a principal name (just uid). I vaguely recall that the reason for returning
NFS4ERR_CLID_INUSE was to subvert a denial of service attack via replay.
If that is correct, then it doesn't seem that it should matter what
happens for AUTH_SYS. (ie. You should only be allowing "trusted" clients
to use AUTH_SYS, since they can do lots of other nasty things beyond denial
of service.)

As such, I'm thinking that the check in SetClientID for same principal
should pass so long as the field before "@host.domain" matches the user
name that the uid equates to, when either the old or current SetClientID
is using AUTH_SYS. (In other words, AUTH_SYS with uid==0 would be the
same as any principal that is root@<host.domain>.) For AUTH_SYS, I thought
about trying to get the client's <host.domain> via reverse name resolution
using DNS for the IP#, but am afraid that reverse name resolution is too
flakey to be of any real benefit.

Does this make sense? rick

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

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Mon, 13 Dec 2004 10:51:31 -0500

IMHO, it's all in the name to id mapping configuration.
if the principal name in the RPCSEC_GSS transport of the SETCLIENTID call maps 
to the same UID of the previous client incarnation setclientid principal, then 
the names are the same. otherwise, NFS4ERR_CLID_IN_USE should be returned.

so, compare UIDs.

-->Andy