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): openssh-3.5p1-6 How reproducible: Always 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 nameserver ... 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: non-root: $ 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" root: # 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 rawhide). ge
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. Thanks!