Bug 223452 - rlogind refuses connections if nameserver(s) down
rlogind refuses connections if nameserver(s) down
Product: Fedora
Classification: Fedora
Component: rsh (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Adam Tkac
Ben Levenson
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2007-01-19 09:58 EST by Jeremy Faith
Modified: 2013-04-30 19:34 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-16 09:42:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jeremy Faith 2007-01-19 09:58:16 EST
Description of problem:
rlogind refuses connections if nameserver(s) down or not configured

Version-Release number of selected component (if applicable):

How reproducible:
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 fc6_machine 
Actual results:
$ rsh grima
n.rlogind: network.c:130: find_hostname: Assertion `error == 0' failed.

Expected results:
$ ssh grima
jjf@grima's password:

Additional info:
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.
Comment 1 Adam Tkac 2007-01-22 08:47:21 EST
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
Comment 2 Jeremy Faith 2007-01-22 09:19:14 EST
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.
Comment 3 Adam Tkac 2007-01-22 11:12:14 EST
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 "" for address instead of
correct "www.redhat.com"). This behavior improved security. Closing as notabug
Comment 4 Jeremy Faith 2007-01-22 11:18:22 EST
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!
Comment 5 Adam Tkac 2007-01-22 11:59:10 EST
(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 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 ( And this is your main
problem. If DNS server isn't avaliable on server's side (removed
/etc/resolf.conf) 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, reverse DNS record is
that IP has name grima). You must type password in both cases.
Do you understand why this is not a bug but this is feature?
Comment 6 Jeremy Faith 2007-01-22 12:17:58 EST
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
that far.

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.
Comment 7 Adam Tkac 2007-04-10 12:59:39 EDT
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.

Regards, -A-
Comment 8 Jeremy Faith 2007-04-11 05:18:56 EDT
I have tested the new version you have supplied and it does allow login when -D
is specified.
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.
Comment 9 Adam Tkac 2007-04-11 09:01:21 EDT
In the end you influenced me. You could test next version of proposed update :)

Comment 10 Jeremy Faith 2007-04-11 12:25:08 EDT
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
.rhosts directly.

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?
Comment 11 Adam Tkac 2007-04-11 12:55:09 EDT
(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-
Comment 12 Adam Tkac 2007-09-25 12:22:48 EDT
After next investigation patch for this issue will be far more better - reopening
Comment 13 Chuck Mead 2007-10-05 11:33:13 EDT
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?
Comment 14 Adam Tkac 2007-10-16 09:42:35 EDT
with final Fedora 8 rsh no option is needed and -D will be removed in Fedora 9

Note You need to log in before you can comment on or make changes to this bug.