On 04/02, Eric W. Biederman wrote:
>
> Add exec_id to signal_struct and compare it at a few choice moments.
I really dislike this change no matter what, sorry.
Firstly, task_struct->*_exec_id should simply die (I already have the
patch), or at least they should be moved into signal_struct simply
because this is per-process thing.
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -995,6 +995,10 @@ static int __send_signal(int sig, struct siginfo *info, struct task_struct *t,
> from_ancestor_ns || (info == SEND_SIG_FORCED)))
> goto ret;
>
> + /* Don't allow thread group signals after exec */
> + if (group && (t->signal->exec_id != t->self_exec_id))
> + goto ret;
Hmm. Either we do not need this exec_id check at all, or we should not
take "group" into account; a fatal signal (say SIGKILL) will kill the
whole thread-group.
> @@ -1247,7 +1251,8 @@ struct sighand_struct *__lock_task_sighand(struct task_struct *tsk,
> * must see ->sighand == NULL.
> */
> spin_lock(&sighand->siglock);
> - if (likely(sighand == tsk->sighand)) {
> + if (likely((sighand == tsk->sighand) &&
> + (tsk->self_exec_id == tsk->signal->exec_id))) {
Oh, this doesn't look good to me. Yes, with your approach we probably need
this to, say, ensure that posix-cpu-timer can't kill the process after exec,
but I'd rather add the exit_state check into run_posix_timers().
But OK, suppose that we fix the problems with signal-after-exec.
====================================================================
Now lets fix another problem. A mt exec suceeds and apllication does
sys_seccomp(SECCOMP_FILTER_FLAG_TSYNC) which fails because it finds
another (zombie) SECCOMP_MODE_FILTER thread.
And after we fix this problem, what else we will need to fix?
I really think that - whatever we do - there should be no other threads
after exec, even zombies.
Oleg.
--
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
