Bugzilla – Bug 285
sudo fails if it cannot resolve the local hostname and no MTA is installed
Last modified: 2008-06-10 21:19:55 MDT
If sudo cannot resolve the local hostname (because /etc/hostname is inconsistent with /etc/hosts), which seems to happen a lot (given the number of comments and duplicates on that bug), sudo is supposed to output a warning "Cannot resolve hostname foo" and go on, at least as long as sudoers does not have any host specific rules. However, that breaks if no local MTA is present: Program received signal SIGPIPE, Broken pipe. 0x00007fcef7181bb0 in write () from /lib/libc.so.6 (gdb) bt #0 0x00007fcef7181bb0 in write () from /lib/libc.so.6 #1 0x00007fcef7125ce3 in _IO_file_write () from /lib/libc.so.6 #2 0x00007fcef7125bc4 in _IO_do_write () from /lib/libc.so.6 #3 0x00007fcef7126e20 in _IO_file_close_it () from /lib/libc.so.6 #4 0x00007fcef711adfa in fclose () from /lib/libc.so.6 #5 0x0000000000405d36 in send_mail (line=0x62fe60 "unable to resolve host foo") at ../logging.c:564 #6 0x0000000000406637 in log_error (flags=9, fmt=0x411d08 "unable to resolve host %s") at ../logging.c:432 #7 0x0000000000407cf8 in set_fqdn () at ../sudo.c:1160 #8 0x0000000000408c4d in main (argc=<value optimized out>, argv=<value optimized out>, envp=0x7fffffa46208) at ../sudo.c:608 In that case, sudo just outputs the error and then dies. This makes it hard to fix the problem, since you need sudo for that... This is strikingly similar to bug 283 (same SIGPIPE on nonexisting sendmail, just a different situation), which was marked as fix committed, and is mentioned in CHANGES. But I don't see any code change in between 1.6.9p10 and 1.6.9p12 which would fix that. I still get the same error with p12. Thank you in advance!
Oh, sorry, I was wrong. CHANGES does not mention it in p12, I mixed that up with another change. So I guess the change hasn't been applied to 1.6.9p12 yet. I applied http://www.sudo.ws/cgi-bin/cvsweb/sudo/logging.c.diff?r1=1.168.2.13&r2=1.168.2.14 manually now, but it still dies with SIGPIPE. Replacing the patch with signal (SIGPIPE, SIG_IGN); works for me, though. In the final version this should probably become sigaction(), but it shows that sigprocmask() might not do the right thing here?
sigprocmask() only delays a signal, I was told. Avoiding SIGPIPE entirely is tricky here. When calling write() directly, you will only get a SIGPIPE after attempting another write() after the previous one returned 0. But since fprintf() might cause several write()s, this is hard to control. So I agree that ignoring SIGPIPE while dealing with the mailer is a reasonable approach. If sendmail fails or doesn't exist, there isn't much else sudo could do as a fallback anyway. :-)
I was initially going to ignore the signal but in my tests blocking it worked equally well (and it was a single line change). There may be timing-related or OS-specific behavior at work here so I've changed it to ignore in cvs. The change will be part of sudo 1.7.0rc2, which will be out momentarily.