Description of problem:
If a user with uid!=0 on a host without an FQDN tries to connect to a machine
without specifying the remote machine's FQDN the connect fails, because the name
resolution in openssh pick the hostname as a domainname and ignore any search
statements in resolve.conf.
Name resolution works as expected if the user is root.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Name your client with a non-dotted name, e.g. "host1"
2. Create a /etc/resolve.conf which should resolve host2 to
host2.mydomain, for example:
search mydomain anotherdomain
3. Run "ssh host2" as a non-root user.
Actual Results: The connection fails. An strace shows that openssh uses "host1"
as a possible domain name for host2 (e.g. tries to resolve "host2.host1"). No
attempt is made to use "mydomain" or "anotherdomain" in name resolution.
Expected Results: The openssh client should follow normal resolution semantics,
as it does for uid=0.
I tracked this down to more than openssh. Everything using getaddrinfo ignores
the search list in /etc/resolv.conf, if uid!=0:
$ ltrace telnet omega 2>&1 | grep -A2 getaddrinfo
getaddrinfo("omega", "telnet", 0xbfeb8f50, 0xbfeb8f44) = -2
strncpy(0x0806a4a0, "omega", 1025) = 0x0806a4a0
gai_strerror(-2) = "Name or service not known"
# ltrace telnet omega 2>&1 | grep -A2 getaddrinfo
getaddrinfo("omega", "telnet", 0xbfe4be80, 0xbfe4be74) = 0
gethostbyname_r(0xbff42adf, 0xbfe4be00, 0xbfe49e00, 8192, 0xbfe49df8) = 0
(changed subject, component and also product since this is still present in
I am changing Priority/Severity, because different name resolutions
depending on the application (gethostbyname vs getaddrinfo) and uid
(root vs non-root) can cause security problems.
I have never seen this specific problem. And in any case, the current
code is very different. The various domains listed in
/etc/resolv.conf are definitely tried. I really suspect you to have a
configuration problem since if this would have been a general problem,
lots of people would have had problems (and we did not hear about this).
In case you still have problems with the FC3t2 code, reopen.
I can confirm this was a local configuration issue, LOCALDOMAIN was
set to a wrong value.
But I thought LOCALDOMAIN would only replace the "domain" keyword, not
also the "search" keyword. Perhaps this is still a bug? This seems to
only affect releases up to FC2. I couldn't reproduce it on FC3, it
seems to be fixed there.