> On Sep 19, 2022, at 2:15 PM, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: > >> On Sep 19, 2022, at 1:59 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > >> The same principal is also used by the NFSv4 server to identify itself >> when acting as a client to the NFS callback service according to >> RFC7530 section 3.3.3. >> So what I'm saying is that for the standard NFS client, then '*' is >> probably the right thing to use (with a slight preference for 'host/'), >> but for the NFS server use case of connecting to the callback service, >> it should specify the 'nfs/' prefix. It can do that right now by >> setting the clnt->cl_principal. As far as I can tell, the current >> behaviour in knfsd is to set it to the same prefix as the server >> svc_cred, and to default to 'nfs/' if the server svc_cred doesn't have >> such a prefix. > > The server uses the client-provided service name in this case. > If the client authenticates as "host@" then the server will > authenticate to the "host@" service on the backchannel. > > Maybe the only mismatch is that my server is using > "host@xxxxxxxxxxxxxxxxxxxxx" on the backchannel, and it should > be using "host@xxxxxxxxxxxxxxxxxx" instead? The Linux NFS server uses gssproxy to acquire a credential for the NFS4_CB context. It appears to be using "uname -n" instead of the hostname bound to its InfiniBand network interface -- the latter is what matches the acceptor in the context established by SETCLIENTID, and the former does not. I've filed an issue against gssproxy to get help understanding what's going wrong: https://github.com/gssapi/gssproxy/issues/65 -- Chuck Lever
