Message-Id: <200609041416.03945.ah2@delair.de>
Date:	Mon, 4 Sep 2006 14:16:03 +0200
From:	Andreas Hobein <ah2@...air.de>
To:	Oleg Nesterov <oleg@...sign.ru>
Cc:	Linus Torvalds <torvalds@...l.org>, Andrew Morton <akpm@...l.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Roland McGrath <roland@...hat.com>
Subject: Re: Trouble with ptrace self-attach rule since kernel > 2.6.14

On Saturday 02 September 2006 19:03, Oleg Nesterov wrote:
> On 09/01, Linus Torvalds wrote:
> > On Fri, 1 Sep 2006, Andrew Morton wrote:
> > > On Fri, 1 Sep 2006 09:36:38 +0200
> > >
> > > Andreas Hobein <ah2@...air.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.
>
> I can't say whether it is safe to restore an old behaviour. This all is
> tricky, and there were so many changes in that area since then.
>
> At least we need to remove 'current->tgid != p->tgid' check in
> eligible_child(). Currently this is a dead code. But if we restore an old
> behaviour, this allows to release ->group_leader too early and crash the
> kernel.
>
> I personally do not see other problems right now, but this doesn't mean
> they are not present...
>
> On the other hand, if we are not going to go back, we can remove subtle
> 'tsk->parent->signal->flags & SIGNAL_GROUP_EXIT' check in exit_notify(),
> and a similar one in may_ptrace_stop().

Thank you all for your kind assistance. It turned out that using vfork() or 
clone() would make a considerable redesign of my code necessary. While the 
added overhead from a "real" fork plus communication of the result over pipes 
is still acceptable, I currently have a lack of time to restructure my 
application to work with vfork or clone and its intrinsic restrictions. Also 
some more non-portable code would be added, which discourages me a bit also.

On the other hand I understand that this kernel change helped to fix a number 
of problems while the now forbidden feature of self attaching to threads is 
rarely used and could be achieved by other means like forking before 
attaching.

Since I'm rather clueless with regard to the kernel internals I'm afraid I 
can't add more value to this discussion other than to prove there is at least 
a second application out there being affected by this patch.

Thank you once again and best regards,

	Andreas

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

Powered by blists - more mailing lists