supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: "Ciprian Dorin, Craciun" <ciprian.craciun@gmail.com>
To: supervision@list.skarnet.org, sudo-users@sudo.ws
Subject: Improper setting / resetting of the signals mask
Date: Tue, 14 Sep 2010 14:14:45 +0300	[thread overview]
Message-ID: <AANLkTik39j45XmArWreOJK71hMr561iD0iw04qYXN=2i@mail.gmail.com> (raw)

    Hello all!

    Sorry for cross-posting, but this "bug" is relevant to both
projects (`runit` and `sudo`), so please forgive me in advance. :)

    In short `sudo` doesn't seem to reset (zero out) its inherited
signal mask, and `runit` seems to leave some signals blocked when
exec-ing children. (And the side-effect is breaking some service
management scripts.)

    Now the long story:
    * (`runit` specific) it seems that when `runit` starts the
`./contro/t` script it leaves some signals blocked (at least the mask
0x14000) (see below in the transcript from `ps s $PID`); (it seems
that this happens only for `./contro/X` and not for the `./run`
scripts;)
    * (`sudo` specific) it seems that when `sudo` starts it doesn't
reset the inherited blocked signals, on which it seems to rely for
detecting when the child process finished; (and this only happens with
the latest versions of `sudo` (`1.7.4p3`), because until now sudo
didn't forked and waited for the child but instead it `execve`-d it;
now because it uses the `pam-session` feature it waits for the child
to terminate...)

    The following snippet is part of the `./control/t` script which
only sends `TERM` followed by `KILL` signals to the service. It uses
`sudo` to elevate the rights from my normal user to that of root.
~~~~
#!/bin/bash

set -e +m -u -o pipefail || exit 1
exec 2>&1

echo "before sudo" >>/tmp/transcript.txt
ps s "${$}" >>/tmp/transcript.txt

test "${#}" -eq 0
test "${UID}" -eq 0 || exec sudo -u "#0" -g "#${UID}" -E -P -n -- "${0}" "${@}"

echo "after sudo" >>/tmp/transcript.txt
ps s "${$}" >>/tmp/transcript.txt

pid="$( cat ./supervise/pid )"
test -e "/proc/${pid}" || exit 1
kill -s TERM "${pid}" || true
sleep 0.1s
test -e "/proc/${pid}" || exit 0
sleep 1s
test -e "/proc/${pid}" || exit 0
kill -s KILL "${pid}" || true
exit 0
~~~~

    And the following is the result of running the script. See the
BLOCKED (0x14000) signal mask:
    * the first "before sudo" text and the `ps` output line is before
executing `sudo` (thus showing that `runit` doesn't clear the blocked
signals mask);
    * the second "before sudo" text and the `ps` line is after
executing `sudo` (and before the UID test) and the masks are just like
the previous output (thus showing that sudo doesn't reset the masks);
~~~~
before sudo
  UID   PID          PENDING          BLOCKED          IGNORED
  CAUGHT STAT TTY        TIME COMMAND
10101  5935 0000000000000000 0000000000014000 0000000000000004
0000000000010002 S    ?          0:00 /bin/bash control/t
before sudo
  UID   PID          PENDING          BLOCKED          IGNORED
  CAUGHT STAT TTY        TIME COMMAND
    0  5937 0000000000000000 0000000000014000 0000000000000004
0000000000010002 S    ?          0:00 /bin/bash control/t
~~~~

    And the following is the result of running the same script but
with a minor modification (see the `nosig` wrapper in front of `sudo`
which is just a simple C application that manually clears all signal
masks before `execve`-ing):
    * see that the BLOCKED mask before using `nosig` is the same as in
the previous case, but:
    * by using `nosig` followed by `sudo` the signal masks are cleared
(I think that the "0x10000" signal is blocked by BASH in any case);
~~~~
test "${UID}" -eq 0 || exec nosig sudo -u "#0" -g "#${UID}" -E -P -n
-- "${0}" "${@}"
~~~~
before sudo
  UID   PID          PENDING          BLOCKED          IGNORED
  CAUGHT STAT TTY        TIME COMMAND
10101  6067 0000000000000000 0000000000014000 0000000000000004
0000000000010002 S    ?          0:00 /bin/bash control/t
before sudo
  UID   PID          PENDING          BLOCKED          IGNORED
  CAUGHT STAT TTY        TIME COMMAND
    0  6069 0000000000000000 0000000000010000 0000000000000004
0000000000010002 S    ?          0:00 /bin/bash control/t
~~~~

    So thank you for paying attention to my report, and I hope it'll
be helpful for the developers.
    Ciprian.


             reply	other threads:[~2010-09-14 11:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-14 11:14 Ciprian Dorin, Craciun [this message]
2010-09-14 13:49 ` Todd C. Miller
2010-09-14 20:22 ` Laurent Bercot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AANLkTik39j45XmArWreOJK71hMr561iD0iw04qYXN=2i@mail.gmail.com' \
    --to=ciprian.craciun@gmail.com \
    --cc=sudo-users@sudo.ws \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).