On Mon, 30 Jul 2018, Jürg Billeter wrote: > On Mon, 2018-07-30 at 12:17 +0200, Oleg Nesterov wrote: > > On 07/30, Jürg Billeter wrote: > > > > > > This is required for job control in a shell that uses CLONE_NEWPID for > > > child processes. > > > > Could you explain in more details? > > The SIGNAL_UNKILLABLE flag, which is implicitly set for tasks cloned > with CLONE_NEWPID, has the effect of ignoring all signals (from > userspace) if the corresponding handler is set to SIG_DFL. The only > exceptions are SIGKILL and SIGSTOP and they are only accepted if raised > from an ancestor namespace. > > SIGINT, SIGQUIT and SIGTSTP are used in job control for ^C, ^\, ^Z. > While a task with the SIGNAL_UNKILLABLE flag could install handlers for > these signals, this is not sufficient to implement a shell that uses > CLONE_NEWPID for child processes: > > * As SIGSTOP is ignored when raised from the SIGNAL_UNKILLABLE process > itself, I don't think it's possible to implement the stop action in > a custom SIGTSTP handler. > * Many applications do not install handlers for these signals and > thus, job control won't work properly with unmodified applications. > > Job control in a shell is just an example. There are other scenarios, > of course, where applications rely on the default actions as described > in signal(7), and PID isolation may be useful. In my opinion, the > kernel support for preventing accidental killing of the "init" process > should really be optional and this new prctl provides this without > breaking backward compatibility. This makes sense and exactly that information needs to be in the changelog. Thanks, tglx
