Red Hat Bugzilla – Bug 223452
rlogind refuses connections if nameserver(s) down
Last modified: 2013-04-30 19:34:43 EDT
Description of problem:
rlogind refuses connections if nameserver(s) down or not configured
Version-Release number of selected component (if applicable):
either disconnect nameservers from network or delete /etc/resolv.conf
rsh into server from a client not listed in /etc/hosts
Steps to Reproduce:
1. on FC6 server
rm /etc/resolv.conf #or disconnect nameservers from network
2. on a client machine not listed in /etc/hosts on server
$ rsh grima
n.rlogind: network.c:130: find_hostname: Assertion `error == 0' failed.
$ ssh grima
This bug is due to a change in the glibc getnameinfo function, see bug 221583
and bug 204122.
If a nameserver is not available, getnameinfo now returns the EAI_AGAIN
error(even when the NI_NAMEREQD flag is not set) rather than returning the IP
address as a string as it used to.
Could you tell me what exactly you expected, please? I think all is ok. Please
look at -D option. This option disable host checking so all could works fine
It is the change to way the getnameinfo function works that has caused this issue.
If getnameinfo was unable to determine the hostname from the IP address for any
reason getnameinfo used to return the IP address in string form. But now
getnameinfo returns EAI_AGAIN if the nameserver is down or not configured. I
think this is really a problem with glibc but others disagree, see bug 221583.
I think if the EAI_AGAIN error occurs the IP address should be converted to
string form as this will restore the previous behaviour.
The -D option does not seem to be mentioned in the rlogind manual page.
But looking as the source code the find_hostname function does the getnameinfo
function call before the no_host_check variable is used. So the
'assert(error==0);' statement will still happen even if the -D option is used.
As I have said, this is due to the change in the behaviour of the getnameinfo
function. I suspect the getnameinfo change breaks lots of programs e.g. I have
logged the same issue against telnetd see bug 223448.
This isn't a bug. Please see $ man rexecd and -D option. This option disables
checking of DNS reverse. If getnameinfo returns nonzero value that means it's no
way how to determine reverse from IP address now. (for example getnameinfo
returns EAI_AGAIN, name "126.96.36.199" for address 188.8.131.52 instead of
correct "www.redhat.com"). This behavior improved security. Closing as notabug
This is a bug.
I am NOT talking about automated authentication without prompting for a password
which clearly does required the name.
I am talking about the situation where someone tries to run rsh to log into a
server WITH a password but this fails as the nameserver is down!
(In reply to comment #4)
> This is a bug.
> I am NOT talking about automated authentication without prompting for a password
> which clearly does required the name.
> I am talking about the situation where someone tries to run rsh to log into a
> server WITH a password but this fails as the nameserver is down!
Looks like you don't understand. I'm going to try explain you why this isn't a
bug. This is what exactly happens
You type on client $rsh grima. DNS server (nameserver, listen in client's
/etc/resolf.conf) translates name grima to IP address (for example
184.108.40.206). Then rsh connects to server by this IP. You have dead right
that server could only get password now and all could works fine (this behavior
could be set by -D parameter to rsh server, view man rexecd, please). But this
behavior could be quite vulnerable. Without -D parameter rsh server try
determine name (grima) from IP address (220.127.116.11). And this is your main
problem. If DNS server isn't avaliable on server's side (removed
/etc/resolf.conf) 18.104.22.168 can't be translated to name grima. In this
case getnameinfo returns non-zero value and server immediatly closes connection.
This is security issue because attacker usually don't have reverse DNS record
(DNS record is that name grima has IP 22.214.171.124, reverse DNS record is
that IP 126.96.36.199 has name grima). You must type password in both cases.
Do you understand why this is not a bug but this is feature?
The test that prevents rlogind working happens before the -D option has any
effect, i.e. the problem happens even when -D is given.
I expect to have to enter the password, the problem is that rloingd does not get
To explain a little further:-
If a client for which there is no name in the nameserver attempts to ssh into
the server and the nameserver IS available getnameinfo returns the IP address
instead of the name and rlogind works as expected.
But due to the getnameinfo change if the nameserver is NOT available getnameinfo
returns an EAI_AGAIN error instead of returning the IP address.
I've done improved version of -D option to rlogind. Now all reverse checking is
disabled (with -D option). Could you please test proposed update and tell me
your results? For me all works fine.
I have tested the new version you have supplied and it does allow login when -D
But if -D is specified automatic logins do not work even if the host is
specified in the .rhosts file using the IP address.
May I ask what is wrong with the idea of converting the IP address to numeric
form if gethostnameinfo returns EAI_AGAIN?
For the time being my workaround has been to remove dns from the hosts line in
the /etc/nsswitch.conf file.
In the end you influenced me. You could test next version of proposed update :)
Yes, that seems to work well, thank you.
As expected it asks for a password if .rhosts is not setup.
Automatic login works if hostname is in /etc/hosts and .rhosts or if IP is in
Using getnameinfo again with NI_NUMERICHOST set is a neat way to do the
conversion, I was thinking inet_ntoa but that would probably not have worked for
I may be going a little mad as I thought a note about the -D option had been
added to the rlogind manual page but I do not see it now.
I must admit I am a little unclear on how an adding the -D option reduces
security though. If someone is spoofing an IP address then surely the reverse
DNS will still resolve?
Also I logged bug #223448 against telnetd as it has a similar issue, will this
be fixed as well?
(In reply to comment #10)
When your resolv.conf contains nothing it's no way how to get reverse DNS. With
-D option reverse checking is disabled. Security is lower so you must know what
you're doing when you start rlogind with -D option. I'm going to update manpage
and push this update to rawhide.
Thank you for cooperation, -A-
After next investigation patch for this issue will be far more better - reopening
So how is this coming along? The reason I ask is we're having some issues with
rsh-server ourselves. When the hosts file is really large clients take forever
to be connected... something exceeding 30 seconds. Notably when connecting to a
sun host with the same exact hosts file connection is almost immediate. Comments?
with final Fedora 8 rsh no option is needed and -D will be removed in Fedora 9