Re: Improper setting / resetting of the signals mask

[Laurent Bercot <ska-supervision@skarnet.org>]

>     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.)

 Hello Ciprian,
 If you're going to blame sudo for not resetting the signal mask,
why not also blame bash, which is executed between runsv and sudo ? :)
It seems natural to think that a shell should reset the sigprocmask.
I just checked SUSv3, which says nothing about that; so, by default,
ignoring the sigprocmask is probably the right thing to do, and
bash (for once) gets it right.

 It is debatable whether sudo should be paranoid and also unblock
signals. On the one hand, the *point* of sudo is to be paranoid. On
the other hand, applications can and generally should expect to be
executed in a sane environment, and be liberal in what they accept
(i.e. they should not arbitrarily close fds or remove environment
variables, for instance - and I don't think they should arbitrarily
unblock signals either).

 What is certain is that runsv does the wrong thing here: blocked
signals should definitely be unblocked before exec'ing an external
command. I'm sure Gerrit will agree and fix that in a next release.

 In the meantime, let me suggest 2 workarounds:

 - You can use the 'trap' shell command to manually unblock signals.
SUSv3 does not even specify that using 'trap' should unblock the
trapped, or defaulted, signals, but not doing it would be clearly
absurd. 'trap - TERM' and you should be rolling.

 - In this precise case, you don't even need sudo. If all you want
is to give user 'joe' enough rights to control /service/foo, you
can make /service/foo/supervise/control writable by 'joe'. For
instance:
# chown joe /service/foo/supervise/control

 Then, no need for elaborate control scripts: all the complexity
of the script can be moved to the client side, and joe just runs
'sv force-restart /service/foo' when appropriate.

-- 
 Laurent