Re: [PATCH 09/16] ptrace: make do_signal_stop() use ptrace_stop()if the task is being ptraced

[Tejun Heo]

On Thu, Dec 23, 2010 at 05:06:48PM +0100, Oleg Nesterov wrote:
> > Yes, before the change, the task would respond to SIGCONT before the
> > first ptrace request succeeds after attach.
> 
> Not exactly. But perhaps you meant that even without this change,
> any ptrace() request after ptrace(PTRACE_CONT, SIGSTOP) will change
> child->state = TASK_TRACED, and kill(SIGCONT) won't work after that.

Yeap, exactly.

> > To me, this doesn't seem to be anything intentional tho.  It seems
> > a lot of ptrace and group stop interactions is in the grey area
> > with only the current (quirky, I'm afraid) behavior drawing almost
> > arbitrary lines across different behaviors.
> 
> Agreed.
> 
> However. Strangely, I didn't think about this before. With this
> change, it is not possible to trace/debug the application so that
> it can properly react to SIGCONT. Yes, currently we have a lot
> more problems here, including do_wait, so probably this doesn't
> matter.
> 
> Still I'd like to know what Jan and Roland think. I am paranoid,
> yes ;)

Definitely.

Hmm... the mention of SIGCONT behavior reminds me of your mention of
notification behavior on the other message.  I might write a more
detailed reply there but, anyways, I don't think we'll be able to find
one good behavior with the current set of operations.  If we hide the
group stop handling and notification from the ptracer, it would allow,
for example, transparent strace, but it will at the same time restrict
what a debugger can do behind the tracee's back in a regressive way
(ie. the current users would notice).

I think it would be better to introduce a few new ptrace operations
and give them more control in clearly defined and hopefully intutive
way.  For example, a ptracer is notified when a task is stopping for
group stop and it should be able to decide and tell the kernel whether
to participate in the group stop or not.  For SIGCONT, likewise, the
kernel can notify all ptracers in the group and can notify the real
parent if all ptracers decide to participate in the continuation.

That way, debuggers can still work behind the real parent's back (they
often want to) while audit type tools can sniff transparently.  I
think the trickier part would be adapting the existing operations so
that they have clearly defined (mostly) compatible behavior while not
hindering too much with addition of new capabilities.

Thanks.

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