Bug 479464

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