linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Pedro Alves <palves@redhat.com>
Cc: Denys Vlasenko <vda.linux@googlemail.com>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Dmitry Vyukov <dvyukov@google.com>,
	Alexander Potapenko <glider@google.com>,
	Eric Dumazet <edumazet@google.com>,
	Jan Kratochvil <jan.kratochvil@redhat.com>,
	Julien Tinnes <jln@google.com>, Kees Cook <keescook@google.com>,
	Kostya Serebryany <kcc@google.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>,
	Robert Swiecki <swiecki@google.com>,
	Roland McGrath <roland@hack.frob.com>,
	syzkaller@googlegroups.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: [PATCH 1/2] wait/ptrace: always assume __WALL if the child is traced
Date: Wed, 28 Oct 2015 17:11:52 +0100	[thread overview]
Message-ID: <20151028161152.GA24042@redhat.com> (raw)
In-Reply-To: <562E17D8.4000108@redhat.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.


  reply	other threads:[~2015-10-28 15:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-20 17:17 [PATCH 0/2] wait/ptrace: always assume __WALL if the child is traced Oleg Nesterov
2015-10-20 17:17 ` [PATCH 1/2] " Oleg Nesterov
2015-10-20 22:31   ` Andrew Morton
2015-10-21  3:27     ` Vasily Averin
2015-10-21 17:41     ` Oleg Nesterov
2015-10-21 19:47       ` Andrew Morton
2015-10-21 20:44         ` Oleg Nesterov
2015-10-21 19:59     ` Denys Vlasenko
2015-10-21 20:31       ` Denys Vlasenko
2015-10-21 21:47         ` Oleg Nesterov
2015-10-21 23:27           ` Denys Vlasenko
2015-10-25 15:54             ` Oleg Nesterov
2015-10-26 12:08               ` Pedro Alves
2015-10-28 16:11                 ` Oleg Nesterov [this message]
2015-10-28 15:43                   ` Pedro Alves
2015-10-28 19:02                     ` Oleg Nesterov
2015-10-22 13:51   ` Denys Vlasenko
2015-10-20 17:17 ` [PATCH 2/2] wait: allow sys_waitid() to use __WNOTHREAD/__WCLONE/__WALL Oleg Nesterov
2015-10-20 17:36 ` [PATCH 0/2] wait/ptrace: always assume __WALL if the child is traced Oleg Nesterov
2015-10-22 14:40 ` Pedro Alves
2015-10-25 15:42   ` Oleg Nesterov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151028161152.GA24042@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dvlasenk@redhat.com \
    --cc=dvyukov@google.com \
    --cc=edumazet@google.com \
    --cc=gdb@sourceware.org \
    --cc=glider@google.com \
    --cc=jan.kratochvil@redhat.com \
    --cc=jln@google.com \
    --cc=kcc@google.com \
    --cc=keescook@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=palves@redhat.com \
    --cc=roland@hack.frob.com \
    --cc=swiecki@google.com \
    --cc=syzkaller@googlegroups.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vda.linux@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).