Description of problem: fedora 7 sudo does not query nameservers nor hang (expected) fedora 10 sudo/pam/something does hit nameservers if /etc/resolv.conf has a nameserver, and hostname is not in /etc/hosts, and can hang for about 30 seconds if network is down/not configured. Note sudo will eventually continue successfully, but you can't even interrupt it with control-c while it is hung - making you think the whole kernel is hung. Version-Release number of selected component (if applicable): pam-1.0.2-2.fc10.i386 sudo-1.6.9p17-2.fc10.i386 How reproducible: Always Steps to Reproduce: 1. put a nameserver in /etc/resolv.conf 2. set hostname to something like 'mybox' 2. add Defaults !syslog in /etc/sudoers 3. (as root) strace -e connect sudo echo hi Otherwise my syslog is simply standard : ## Allow root to run any commands anywhere root ALL=(ALL) ALL Actual results: ... connect(5, {sa_family=AF_FILE, path="/var/run/nscd/socket"...}, 110) = -1 ENOENT (No such file or directory) connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.5.180")}, 28) = 0 connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.5.180")}, 28) = 0 connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.5.180")}, 28) = 0 ... lots more :( Here is the tcpdump: 20:05:29.517648 IP 192.168.5.30.34811 > 192.168.5.180.domain: 29897+ AAAA? webfilter. (27) 20:05:29.518075 IP 192.168.5.180.domain > 192.168.5.30.34811: 29897 ServFail 0/0/0 (27) 20:05:29.518837 IP 192.168.5.30.58244 > 192.168.5.180.domain: 29897+ AAAA? webfilter. (27) 20:05:29.519710 IP 192.168.5.180.domain > 192.168.5.30.58244: 29897 ServFail 0/0/0 (27) 20:05:29.520536 IP 192.168.5.30.54293 > 192.168.5.180.domain: 43633+ A? webfilter. (27) 20:05:29.520958 IP 192.168.5.180.domain > 192.168.5.30.54293: 43633 ServFail 0/0/0 (27) 20:05:29.522073 IP 192.168.5.30.38551 > 192.168.5.180.domain: 43633+ A? webfilter. (27) 20:05:29.522486 IP 192.168.5.180.domain > 192.168.5.30.38551: 43633 ServFail 0/0/0 (27) 20:05:29.527917 IP 192.168.5.30.49290 > 192.168.5.180.domain: 49864+ AAAA? webfilter. (27) It is trying to lookup the hostname (webfilter) - why? Expected results: Should not hit nameservers or otherwise access network when sudo is only being used on the same box. Additional info:
I have tracked down the problem to this call in auth/pam.c. I commented out the last line of PAM_RHOST and now nameservers are not hit. /* * Set PAM_USER to the user we are changing *to* and * set PAM_RUSER to the user we are coming *from*. * We set PAM_RHOST to avoid a bug in Solaris 7 and below. */ (void) pam_set_item(pamh, PAM_USER, pw->pw_name); (void) pam_set_item(pamh, PAM_RUSER, user_name); //(void) pam_set_item(pamh, PAM_RHOST, user_host); // stop hitting my nameservers
(In reply to comment #0) > ... hostname is not in /etc/hosts ... > ... > 2. set hostname to something like 'mybox' I don't think this is a bug in sudo. You have to put a record for 'mybox' into /etc/hosts (or setup a local nameserver).
So what you're saying is, it's perfectly fine for a tool that we use to configure our network to DEPEND on the network being configured properly? No. It is completely unacceptable for sudo to rely on a working network setup with NO WAY to turn that requirement off. We use sudo to edit /etc/hosts and /etc/resolv.conf. Actually our customers do, ours is an appliance platform. And if they enter the wrong nameserver they are going to get really pissed when they try to do anything else and sudo hangs. The security implications are disastrous as well. For a suid program to generate ipv4 and ipv6 requests for no reason by default is just begging for exploits.
(In reply to comment #1) > I have tracked down the problem to this call in auth/pam.c. > I commented out the last line of PAM_RHOST and now nameservers are not hit. > > /* > * Set PAM_USER to the user we are changing *to* and > * set PAM_RUSER to the user we are coming *from*. > * We set PAM_RHOST to avoid a bug in Solaris 7 and below. > */ > (void) pam_set_item(pamh, PAM_USER, pw->pw_name); > (void) pam_set_item(pamh, PAM_RUSER, user_name); > //(void) pam_set_item(pamh, PAM_RHOST, user_host); // stop hitting my > nameservers Sudo doesn't rely on a working network setup, not directly - only through pam_set_item and this dependency is not documented. The line you commented out is there for one year now (http://www.sudo.ws/cgi-bin/cvsweb/sudo/auth/pam.c.diff?r1=1.43.2.4&r2=1.43.2.5&f=h). So, the problem is pam_set_item(..., PAM_RHOST, ...) which is probably trying to resolve your IP which is not possible because your IP doesn't have a record in /etc/hosts nor a record available through nameservers listed in /etc/resolv.conf. I'm closing this as NOTABUG. If you still think that it is something that should be fixed in sudo and not in libpam or by a proper DNS/hosts configuration, feel free to reopen this bug.
I ran into this same problem on an appliance platform that I am developing using Fedora 12. I believe the problem should be fixed in sudo's source code by wrapping the lines of code in question with #ifndef __LINUX_PAM__ or similar. If this code is really just a work around for Solaris 7 there is very little reason for it to be having negative consequences on Fedora. The behavior of pam is correct, but there is no reason for sudo to set the PAM_RHOST unless it needs to work around the apparent bug in Solaris 7 and below. With that block of code (the comment and 2 lines of code mentioned above) wrapped as described the 20+ second delay I was seeing is gone.
Should this be re-opened? Reported upstream?
It is still a bug, and as I mentioned it seems like the problem is caused by running code intended to fix a Solaris problem no matter the platform. Sadly, I didn't have time to decipher bugzilla enough to submit a new bug or re-open this one.
Can we please get this ASSIGNED again with Joseph's solution?
Fixed in upstream version 1.7.5 (July 2010)? http://www.sudo.ws/repos/sudo/rev/1e10105ade5b