Bug#728255: rpc.gssd: Cannot determine realm for numeric host address
Package: nfs-common
Version: 1:1.2.6-4
This appears to be a regression caused by the fix for CVE-2013-1923.
Symptoms (hostnames and IP addresses have been changed but nothing else):
Oct 29 14:29:39 MYHOST rpc.gssd[15905]: ERROR: Cannot determine realm for numeric host address while getting realm(s) for host '192.0.2.34'
Oct 29 14:29:39 MYHOST rpc.gssd[15905]: ERROR: gssd_refresh_krb5_machine_credential: no usable keytab entry found in keytab /etc/krb5.keytab for connection with host 192.0.2.34
Oct 29 14:29:39 MYHOST kernel: [1321146.189554] RPC: AUTH_GSS upcall timed out.
Oct 29 14:29:39 MYHOST kernel: [1321146.189557] Please check user daemon is running.
Oct 29 14:29:39 MYHOST rpc.gssd[15905]: ERROR: Cannot determine realm for numeric host address while getting realm(s) for host '192.0.2.34'
Oct 29 14:29:39 MYHOST rpc.gssd[15905]: ERROR: gssd_refresh_krb5_machine_credential: no usable keytab entry found in keytab /etc/krb5.keytab for connection with host 192.0.2.34
It doesn't happen particularly often; maybe a couple of times a day on
this (admittedly lightly loaded) system.
What I think is happening here is that:
(a) the kernel (3.2.0-4-686-pae #1 SMP Debian 3.2.51-1 i686 GNU/Linux)
sometimes publishes a numeric IP address instead of the server name
in the first line of /var/lib/nfs/rpc_pipefs/nfs/clnt*/info ;
(b) when this happens, utils/gssd/gssd_proc.c:get_servername()
(with avoid_dns==1 since the security fix) simply returns "192.0.2.34"
instead of calling getnameinfo();
(c) utils/gssd/krb5_util.c:get_full_hostname() only calls getaddrinfo(),
not getnameinfo(), and returns "192.0.2.34" when fed "192.0.2.34" as input;
(d) krb5_get_host_realm() doesn't know the realm name for "192.0.2.34".
I'll try the new -D option, but this just disables the security fix.
I wonder if the security fix has been coded correctly. The associated
comments say that the intent is not to do DNS lookups on server names,
but "[i]f it is an IP address, do the DNS lookup". The logic, however,
seems reversed. Could someone please double-check this? (I'm fairly
confident that I'm not misreading the code; what I'd like a second
opinion on is the coder's intent and the security implications of
reversing the logic.)
Another question is why the kernel upcall sometimes (not very often)
refers to the server by IP address instead of by name. There may be
a kernel bug lurking here.
Reply to: