Cryptic error from sudo when /usr/sbin/sendmail doesn't exist

Bug #193516 reported by Martin Stjernholm on 2008-02-19
Affects Status Importance Assigned to Milestone
Fix Released
sudo (Ubuntu)

Bug Description

Binary package hint: sudo

I have set up a 32 bit chroot environment on my 64 bit system using schroot. In this environment I have a problem using sudo:

  kolon:~/doc> schroot
  I: [chroot-32 chroot] Running login shell: ‘/bin/tcsh’
  kolon[i686]:~/doc> sudo ls
  [sudo] password for mast:
  Broken pipe
  kolon[i686]:~/doc> sudo ls
  Broken pipe

All I get from sudo from this point on is this "Broken pipe" error. As can be seen above, sudo manage to ask for and verify my password (if I type in the wrong password, sudo correctly asks again), the problem occur later.

I suspect this is due to a mistake I've made in setting up this 32 bit chroot environment. I use a lot of bind mounts to share as much as possible between the chroot environment and my real 64 bit environment:

/dev /chroot-32/dev none bind 0 0
/etc/apt /chroot-32/etc/apt none bind 0 0
/etc/group /chroot-32/etc/group none bind 0 0
/etc/gshadow /chroot-32/etc/gshadow none bind 0 0
/etc/passwd /chroot-32/etc/passwd none bind 0 0
/etc/resolv.conf /chroot-32/etc/resolv.conf none bind 0 0
/etc/shadow /chroot-32/etc/shadow none bind 0 0
/home /chroot-32/home none bind,rshared 0 0
/proc /chroot-32/proc none bind 0 0
/sys /chroot-32/sys none bind 0 0
/tmp /chroot-32/tmp none bind 0 0
/var/run /chroot-32/var/run none bind 0 0
/var/tmp /chroot-32/var/tmp none bind 0 0

Note that the bug here might not be that the error happens, but rather that it's reported with a bad error message that doesn't give me any hint about what to look for.

sudo version is 1.6.8p12-5ubuntu2


Martin Stjernholm (msub) wrote :

strace'ing the problem revealed the reason for the cryptic error:

# strace -u mast sudo ls
pipe([4, 5]) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2b34bf991b80) = 15504
close(4) = 0
fcntl(5, F_GETFL) = 0x1 (flags O_WRONLY)
fstat(5, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b34bf029000
lseek(5, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1892, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1892, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1892, ...}) = 0
write(5, "To: root\nFrom: mast\nSubject: ***"..., 176) = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
+++ killed by SIGPIPE +++

One can see here that the broken pipe comes from trying to pipe a mail to a subprocess. Tracing that one too reveals:

dup2(4, 0) = 0
close(4) = 0
close(5) = 0
close(3) = 0
setgid(1021) = 0
setreuid(1021, 1021) = 0
execve("/usr/sbin/sendmail", ["/usr/sbin/sendmail", "-t"], [/* 4 vars */]) = -1 ENOENT (No such file or directory)
exit_group(127) = ?

I.e. /usr/sbin/sendmail doesn't exist. (The error that sudo tried to mail was that my user didn't exist in /etc/sudoers.)

Note that this has nothing to do with the chroot environment as I suspected, but rather that sudo doesn't gracefully handle the case when /usr/sbin/sendmail doesn't exist. I was able to reproduce the same problem outside the chroot.

Martin Pitt (pitti) wrote :

I tried it under similar conditions: dapper chroot, my user not in sudoers, but I have a password in /etc/shadow, so that PAM can actually authenticate me. I just get

  $ sudo ls
  martin is not in the sudoers file. This incident will be reported.

without a "Broken pipe" error message, but I understand that this is subject to a race condition. My strace -f output also contains similar output, and a quick inspection of logging.c, send_mail() shows that this hasn't been fixed in Hardy yet.

Changed in sudo:
importance: Undecided → Low
status: New → Confirmed
Changed in sudo:
status: Unknown → Fix Released
Neal McBurnett (nealmcb) wrote :

See also
Is this now fixed in hardy-proposed for you?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.