On Fri, 2018-08-03 at 08:34 -0500, Eric W. Biederman wrote:
From the other direction I think we can just go ahead and fix handling
of the job control stop signals as well. As far as I understand it
there is a legitimate complaint that SIGTSTP SIGTTIN SIGTTOU do not work
on a pid namespace leader.
The current implementation actual overshoots. We only need to ignore
signals from the descendants in the pid namespace. Ideally signals from
other processes are treated like normal. We have only been able to
apply that ideal to SIGSTOP and SIGKILL as we can handle them in
prepare_signal. Other signals can be blocked which means the logic to
handle them needs to live in get_signal where we may have no sender
information.
SIGINT and SIGQUIT are also relevant for job control. Would the same
approach be possible for them?
And I would like to allow regular POSIX signal behavior also for
signals used outside job control, e.g., SIGTERM, for maximum
compatibility with existing applications. Furthermore, it would also be
good to allow a PID namespace leader to send a signal to itself.
Do you think we can and should cover all of the above without a prctl
by loosening the restrictions imposed by SIGNAL_UNKILLABLE (with
reasonable effort)?
In my opinion, my patch still makes sense as it simply allows regular
POSIX signal behavior for PID namespace leaders and it doesn't risk any
compatibility issues as the behavior doesn't change at all for
processes that don't invoke the new prctl. I.e., simple patch, low
risk, and covers all signals.
In the meantime I've tested the missing patch for copy_process() and
will send out v3 of the patch in case the new prctl makes sense after
all.
Jürg