This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/2] wait/ptrace: always assume __WALL if the child is traced
- From: Oleg Nesterov <oleg at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Denys Vlasenko <vda dot linux at googlemail dot com>, Denys Vlasenko <dvlasenk at redhat dot com>, Andrew Morton <akpm at linux-foundation dot org>, Dmitry Vyukov <dvyukov at google dot com>, Alexander Potapenko <glider at google dot com>, Eric Dumazet <edumazet at google dot com>, Jan Kratochvil <jan dot kratochvil at redhat dot com>, Julien Tinnes <jln at google dot com>, Kees Cook <keescook at google dot com>, Kostya Serebryany <kcc at google dot com>, Linus Torvalds <torvalds at linux-foundation dot org>, "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>, Robert Swiecki <swiecki at google dot com>, Roland McGrath <roland at hack dot frob dot com>, syzkaller at googlegroups dot com, Linux Kernel Mailing List <linux-kernel at vger dot kernel dot org>, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Wed, 28 Oct 2015 17:11:52 +0100
- Subject: Re: [PATCH 1/2] wait/ptrace: always assume __WALL if the child is traced
- Authentication-results: sourceware.org; auth=none
- References: <20151020171740 dot GA29290 at redhat dot com> <20151020171754 dot GA29304 at redhat dot com> <20151020153155 dot e03f4219da4014efe6f810b0 at linux-foundation dot org> <5627EE9E dot 8040600 at redhat dot com> <5627F607 dot 4050506 at redhat dot com> <20151021214703 dot GA1810 at redhat dot com> <CAK1hOcP027FAWg5uVDjiFDC+0=dGu5JFJcy9Jij4dY8SBnT4MA at mail dot gmail dot com> <20151025155440 dot GB2043 at redhat dot com> <562E17D8 dot 4000108 at redhat dot com>
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.