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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
