From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84352 invoked by alias); 28 Oct 2015 15:15:37 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 84338 invoked by uid 89); 28 Oct 2015 15:15:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_50,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 28 Oct 2015 15:15:36 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 92BFDDA2; Wed, 28 Oct 2015 15:15:34 +0000 (UTC) Received: from tranklukator.brq.redhat.com (dhcp-1-102.brq.redhat.com [10.34.1.102]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id t9SFFUfg018431; Wed, 28 Oct 2015 11:15:31 -0400 Received: by tranklukator.brq.redhat.com (nbSMTP-1.00) for uid 500 oleg@redhat.com; Wed, 28 Oct 2015 17:11:56 +0100 (CET) Date: Wed, 28 Oct 2015 15:15:00 -0000 From: Oleg Nesterov To: Pedro Alves Cc: Denys Vlasenko , Denys Vlasenko , Andrew Morton , Dmitry Vyukov , Alexander Potapenko , Eric Dumazet , Jan Kratochvil , Julien Tinnes , Kees Cook , Kostya Serebryany , Linus Torvalds , "Michael Kerrisk (man-pages)" , Robert Swiecki , Roland McGrath , syzkaller@googlegroups.com, Linux Kernel Mailing List , "gdb@sourceware.org" Subject: Re: [PATCH 1/2] wait/ptrace: always assume __WALL if the child is traced Message-ID: <20151028161152.GA24042@redhat.com> References: <20151020171740.GA29290@redhat.com> <20151020171754.GA29304@redhat.com> <20151020153155.e03f4219da4014efe6f810b0@linux-foundation.org> <5627EE9E.8040600@redhat.com> <5627F607.4050506@redhat.com> <20151021214703.GA1810@redhat.com> <20151025155440.GB2043@redhat.com> <562E17D8.4000108@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <562E17D8.4000108@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2015-10/txt/msg00107.txt.bz2 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.