Re: [PATCH 1/2] wait/ptrace: always assume __WALL if the child is traced

[Oleg Nesterov]

On 10/26, Pedro Alves wrote:
>
> On 10/25/2015 03:54 PM, Oleg Nesterov wrote:
> >
> > In any case, the real question is whether we should change the kernel to
> > fix the problem, or ask the distros to fix their init's. In the former
> > case 1/2 looks simpler/safer to me than the change in ptrace_traceme(),
> > and you seem to agree that 1/2 is not that bad.
>
> A risk here seems to be that waitpid will start returning unexpected
> (thread) PIDs to parent processes,

I don't see how this change can make the things worse,

> and it's not unreasonable to assume
> that e.g., a program asserts that waitpid either returns error or a
> known (process) PID.

Well. /sbin/init can never assume this, obviously.

> That's not an init-only issue,

Yes. Because we have CLONE_PARENT. So "waitpid either returns error or a
known (process) PID" is only true if you trust your children.

> but something that might affect any
> process that runs a child that happens to decide to
> call PTRACE_TRACEME.
>
> The ptrace man page says:
>
>  "A process can initiate a trace by calling fork(2) and having the resulting
>  child do a PTRACE_TRACEME, followed (typically) by an execve(2)."
>
> Given that, can we instead make the kernel error out on PTRACE_TRACEME issued
> from a non-leader thread?  Then between PTRACE_TRACEME and the parent's
> waitpid, __WALL or !__WALL should make no difference.

Afaics not really. A group leader can do PTRACE_TRACEME and then
clone(CLONE_THREAD | CLONE_PTRACE) with the same effect.

> (Also, in the original test case, if the child gets/raises a signal or execs
> before exiting, the bash/init/whatever process won't be issuing PTRACE_CONT,
> and the child will thus end up stuck (though should be SIGKILLable,

Oh, but if it is killable everything is fine. How does this differ from the
case when, say, you jusr reparent to init and do kill(getpid(), SIGSTOP) ?

> All this because PTRACE_TRACEME is broken by design

Heh. I agree. But we can't fix it now.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/