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

[Andrei Vagin]

On Sun, Mar 25, 2018 at 11:40 AM, Chet Ramey <chet.ramey@case.edu> wrote:
> On 3/23/18 4:34 AM, Andrei Vagin wrote:
>> 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/
>
> I'm glad you put quotes around "documented" before referring to some
> random article.

It is not a random article. Its author is Michael Kerrisk, he is a
maintainer of Linux Man Pages.

And  we can forget about these quotes, because actually this behavior
is described in the pid_namespaces and kill man pages:
http://man7.org/linux/man-pages/man7/pid_namespaces.7.html

       Only signals for which the "init" process has established a signal
       handler can be sent to the "init" process by other members of the PID
       namespace.  This restriction applies even to privileged processes,
       and prevents other members of the PID namespace from accidentally
       killing the "init" process.

http://man7.org/linux/man-pages/man2/kill.2.html

       The only signals that can be sent to process ID 1, the init process,
       are those for which init has explicitly installed signal handlers.
       This is done to assure the system is not brought down accidentally.

>
>
>>>> * 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.
>
> Bash handles fatal signals identically. I understand that the Linux kernel
> changes signal delivery behavior under certain circumstances.
>
>>>> * 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().
>
> If you'd like to submit a patch that does that, I'll take a look.

Will do.

>
> --
> ``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/