lkml.org 
[lkml]   [2006]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Trouble with ptrace self-attach rule since kernel > 2.6.14


On Fri, 1 Sep 2006, Andrew Morton wrote:
> On Fri, 1 Sep 2006 09:36:38 +0200
> Andreas Hobein <ah2@delair.de> wrote:
>
> > There is also a reply from Roland McGrath (see
> > http://lkml.org/lkml/2005/11/9/460) who mentioned that there may occur some
> > problems in "some real programs out there". May be I'm the first one who is
> > affected by this new behaviour.
>
> When you have names, please cc them..

Andreas isn't the first, but in the almost-a-year that the patch has been
part of the kernel, he's the second.

And for the first one I found a reasonable way to avoid the problem: the
debugging thread can do a "vfork()" (or, if vfork() does something bad in
libc, do the direct "clone(CLONE_VFORK|CLONE_MM)" thing) to have a new
thread that is in a _different_ thread group, but is able to ptrace and
also is "synchronized" with the VM, simply because it shares it with all
the other threads it might want to debug.

That "new" (last November) check isn't likely going away. It solved _so_
many problems (both security and stability), and considering that

(a) in a year, only two people have ever even _noticed_
(b) there's a work-around as per above that isn't horribly invasive

I have to say that in order to actually go back to the old behaviour, we'd
have to have somebody who cares _deeply_, go back and check every single
special case, deadlock, and race.

Not allowing ptracing to send signals and be part of the same thread group
really got rid of a _lot_ of complexity (and bugs - I don't mind
complexity per se, but complexity that was known broken and nobody could
really see a good solution for, and had both security and stability
implications is a bad bad thing).

But if somebody does feel that "deep caring feeling", I'll try to help
them. Maybe Roland and Oleg Nesterov might lend a hand too (Oleg in
particular by now probably knows all the races in that area, including
pthread parents sending signals to its own thread and de-parenting etc).

Hint, hint, Andreas. But I think it's a rats' nest, and you'd be better
off trying the CLONE_MM|CLONE_VFORK approach.

Oleg (now added to the Cc) in particular may answer authoritatively
whether maybe his fixes since last year have fixed some of the problems,
or whether they do indeed depend even more on the fact that the ptrace
"fake parent" cannot be in the same thread group.

(Even if we could make it work, I personally much prefer the fact that a
ptrace parent is forced to behave more like a "real parent" - who also
cannot be in the same thread group).

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

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.072 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site