diff options
author | Chuck Lever <chuck.lever@oracle.com> | 2018-08-16 12:06:04 -0400 |
---|---|---|
committer | J. Bruce Fields <bfields@redhat.com> | 2018-08-22 18:32:07 -0400 |
commit | cb25e7b293ec5cd82bc958a6c89dadeb198504b4 (patch) | |
tree | 92ca5be73a6eb66c41790171e0a7e05bb9f9e77f /fs/lockd | |
parent | 9abdda5ddab8a899ca8c4b859ef0a7710f40e0dd (diff) | |
download | linux-cb25e7b293ec5cd82bc958a6c89dadeb198504b4.tar.bz2 |
nfsd: Use correct credential for NFSv4.0 callback with GSS
I've had trouble when operating a multi-homed Linux NFS server with
Kerberos using NFSv4.0. Lately, I've seen my clients reporting
this (and then hanging):
May 9 11:43:26 manet kernel: NFS: NFSv4 callback contains invalid cred
The client-side commit f11b2a1cfbf5 ("nfs4: copy acceptor name from
context to nfs_client") appears to be related, but I suspect this
problem has been going on for some time before that.
RFC 7530 Section 3.3.3 says:
> For Kerberos V5, nfs/hostname would be a server principal in the
> Kerberos Key Distribution Center database. This is the same
> principal the client acquired a GSS-API context for when it issued
> the SETCLIENTID operation ...
In other words, an NFSv4.0 client expects that the server will use
the same GSS principal for callback that the client used to
establish its lease. For example, if the client used the service
principal "nfs@server.domain" to establish its lease, the server
is required to use "nfs@server.domain" when performing NFSv4.0
callback operations.
The Linux NFS server currently does not. It uses a common service
principal for all callback connections. Sometimes this works as
expected, and other times -- for example, when the server is
accessible via multiple hostnames -- it won't work at all.
This patch scrapes the target name from the client credential,
and uses that for the NFSv4.0 callback credential. That should
be correct much more often.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Diffstat (limited to 'fs/lockd')
0 files changed, 0 insertions, 0 deletions