Bug 739 - ignored SIGPIPE stops sudo early in main() after sigprocmask
ignored SIGPIPE stops sudo early in main() after sigprocmask
Status: RESOLVED FIXED
Product: Sudo
Classification: Unclassified
Component: Sudo
1.8.15
PC Linux
: low normal
Assigned To: Todd C. Miller
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-17 03:40 MDT by Sven Peter
Modified: 2016-06-18 06:01 MDT (History)
0 users

See Also:


Attachments
patch to ignore SIGPIPE until init_signals has been called to setup signal handlers (681 bytes, patch)
2016-03-17 03:40 MDT, Sven Peter
Details | Diff
corrected patched. (543 bytes, patch)
2016-03-17 03:47 MDT, Sven Peter
Details | Diff
Ignore SIGPIPE for the duration of sudo and not just in a few select places. (5.23 KB, patch)
2016-03-23 11:00 MDT, Todd C. Miller
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Peter 2016-03-17 03:40:47 MDT
Created attachment 470 [details]
patch to ignore SIGPIPE until init_signals has been called to setup signal handlers

For some reason that I have not been able to figure sudo has an ignored SIGPIPE by the time 
    sigemptyset(&mask);
    sigprocmask(SIG_SETMASK, &mask, NULL);
is reached in main() in src/sudo.c when I use it over ssh. Even moving the sigprocmask to the very first line in the main() functions triggers this behavior for me.
When all signals are enabled the process then terminates because no handlers are installed as of yet. Here's the strace of the problem:
stat("/etc/sudo.conf", 0x7fffb1a39050)  = -1 ENOENT (No such file or directory)
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=29801, si_uid=3733} ---
+++ killed by SIGPIPE +++


For a quick workaround I added sigaddset(&mask, SIGPIPE) before sigprocmask and another call to sigprocmask with an empty mask after init_signals has been called.
Comment 1 Sven Peter 2016-03-17 03:47:37 MDT
Created attachment 471 [details]
corrected patched.
Comment 2 Todd C. Miller 2016-03-17 08:55:56 MDT
Can you provide steps to reproduce the problem?
Comment 3 Sven Peter 2016-03-18 03:39:05 MDT
I wish I could. This is just happening on a single machine and the steps to reproduce on that one are:

% ssh speter@littleheron
speter@littleheron ~ $ sudo
speter@littleheron ~ $ if [[ $? -eq 141 ]]; then echo "failed with SIGPIPE"; fi;
failed with SIGPIPE
speter@littleheron ~ $

i.e. nothing happens and bash doesn't complain because it ignores processes that are terminated with SIGPIPE.
I have absolutely no idea where this SIGPIPE comes from though.
Comment 4 Sven Peter 2016-03-18 03:41:04 MDT
Looks like someone might have run into this problem years ago as well fwiw: https://www.sudo.ws/pipermail/sudo-users/2007-August/003295.html
Comment 5 Todd C. Miller 2016-03-18 10:48:05 MDT
Sudo already ignores SIGPIPE in cases where it is likely to occur but it has no control over what nss or PAM modules might do.  It is probably safest to just ignore SIGPIPE while sudo is running.
Comment 6 Todd C. Miller 2016-03-23 11:00:20 MDT
Created attachment 472 [details]
Ignore SIGPIPE for the duration of sudo and not just in a few select places.

I've attached the patch that I've been testing.
Comment 7 Todd C. Miller 2016-06-18 06:01:35 MDT
Fixed in sudo 1.8.17 which is now available.