On Wed, May 09, 2018 at 05:19:41PM -0400, Chuck Lever wrote: > I'm right on the edge of my understanding of how this all works. > > I've re-keyed my NFS server. Now on my client, I'm seeing this on > vers=4.0,sec=sys mounts: > > May 8 16:40:30 manet kernel: NFS: NFSv4 callback contains invalid cred > May 8 16:40:30 manet kernel: NFS: NFSv4 callback contains invalid cred > May 8 16:40:30 manet kernel: NFS: NFSv4 callback contains invalid cred > > manet is my client, and klimt is my server. I'm mounting with > NFS/RDMA, so I'm mounting hostname klimt.ib, not klimt. > > Because the client is using krb5i for lease management, the server > is required to use krb5i for the callback channel (S 3.3.3 of RFC > 7530). > > After a SETCLIENTID, the client copies the acceptor from the GSS > context it set up, and uses that to check incoming callback > requests. I instrumented the client's SETCLIENTID proc, and I see > this: > > check_gss_callback_principal: acceptor=nfs@xxxxxxxxxxxxxxxxxxxxxxxx, principal=host@xxxxxxxxxxxxxxxxxxxxx > > The principal strings are not equal, and that's why the client > believes the callback credential is bogus. Now I'm trying to > figure out whether it is the server's callback client or the > client's callback server that is misbehaving. > > To me, the server's callback principal (host@klimt) seems like it > is correct. The client would identify as host@manet when making > calls to the server, for example, so I'd expect the server to > behave similarly when performing callbacks. >From the spec point of view, I'm pretty sure the server's in the wrong: it is required to callback as the principal that the client authenticated to on the SETCLIENTID. And the client probably doesn't have much choice about which principal it authenticates to there. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
