Re: bash handles terminate signals incorrectly, when it is run as the init process in a pid namespace

[Andrei Vagin]

On Thu, Mar 22, 2018 at 6:25 PM, Chet Ramey <chet.ramey@case.edu> wrote:
> On 3/22/18 3:38 PM, Andrei Vagin wrote:
>
>> I am thinking how to fix this issue properly. Here are a few points:
>> * bash should know that signals are ignored if a process is the init
>> process in a pid namespace.
>
> Why should it know this? It's not documented, not portable, and conflicts
> with the way signals are documented to behave. This is a situation-specific
> problem.

It is "documented" in many places. For exmaple:
https://lwn.net/Articles/532748/

"""
Signals and the init process
The traditional Linux init process is treated specially with respect
to signals. The only signals that can be delivered to init are those
for which the process has established a signal handler; all other
signals are ignored. This prevents the init process—whose presence is
essential for the stable operation of the system—from being
accidentally killed, even by the superuser.

PID namespaces implement some analogous behavior for the
namespace-specific init process. Other processes in the namespace
(even privileged processes) can send only those signals for which the
init process has established a handler. This prevents members of the
namespace from inadvertently killing a process that has an essential
role in the namespace. Note, however, that (as for the traditional
init process) the kernel can still generate signals for the PID
namespace init process in all of the usual circumstances (e.g.,
hardware exceptions, terminal-generated signals such as SIGTTOU, and
expiration of a timer).
"""

I'm agree that this is a situation-specific problem. Unfortunate, this
situation is quite popular in our days.

>
>> * user and kernel signals (SEGV, SIGFPE, SIGBUS, etc) are handled differently
>
> Fatal signals (signals whose default disposition is to exit the process)
> are pretty much handled identically.

Let's I try to elaborate what I mean.

If we have an init process in a pid namespace, SEGV from the kernel
will kill this process, but SEGV from user will be ignored. So if we
want to handle a kernel SEGV properly, we have to set a default
handler and return back from our handler, the kernel will try to
repeat an instruction what triggered SEGV in a previous time, this
instruction will trigger SEGV again, and the kernel will kill this
process and generate a core file. This trick works for SEGV and FPE,
but it will not work for SIGBUS in some cases...

>
>> * bash should not return back from termsig_sighandler(), if it has
>> sent a signal to itself.
>
> That suggests that the easiest way to solve the problem is to add a call
> to exit() after the kill().

You are right with one exception. We expect that the kernel generates
a core dump file, if a process was killed by SIGSEGV, SIGBUS, SIGFPE,
etc.

For these signals, we probably can dereference an invalid pointer
instead of calling exit().

> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/