Re: [PATCH 08] change ptrace_traceme() to use the new helpers, kill prepare/finish attach

2009-08-19 Thread Oleg Nesterov
On 08/18, Roland McGrath wrote: > > > In particular, this means that > > > > if (event || (clone_flags & CLONE_PTRACE)) { > > child_engine = utrace_attach_task(child, UTRACE_ATTACH_CREATE > > ... > > > > is not right. CLONE_PTRACE should be ignored unless task_ptrace(current).

Re: [PATCH 08] change ptrace_traceme() to use the new helpers, kill prepare/finish attach

2009-08-18 Thread Roland McGrath
> Yes. But we attach to parent->parent, not to parent == current. Ah yes, I see your point. > In short: ptrace_report_clone() should "copy" the tracing state from > current to child when needed. And it should never attach if current > is not traced. Correct. > In particular, this means that >

Re: [PATCH 08] change ptrace_traceme() to use the new helpers, kill prepare/finish attach

2009-08-18 Thread Oleg Nesterov
On 08/17, Roland McGrath wrote: > > > In that case it can share the code with ptrace_traceme(). > > I'm not sure I quite follow that. Both PTRACE_TRACEME and PTRACE_ATTACH > paths have to interlock with each other. Auto-tracing in report_clone > doesn't have to worry about that at all, because of

Re: [PATCH 08] change ptrace_traceme() to use the new helpers, kill prepare/finish attach

2009-08-17 Thread Roland McGrath
> Note: we attach the new engine unconditionally, before security check. > Not good, another task can do ptrace_attach() and get EPERM. Hopefully > we can live with this race, or somehow fix it later. I don't think we can accept that and call it non-regressing. But we can worry about it later. >

[PATCH 08] change ptrace_traceme() to use the new helpers, kill prepare/finish attach

2009-08-17 Thread Oleg Nesterov
Change ptrace_traceme() to use the new helpers. Kill the now unused prepare_ptrace_attach/finish_ptrace_attach. finish_ptrace_attach(ret) logic was wrong. If ->parent has PF_EXITING we must UTRACE_DETACH but ret == 0. Fix this. Note: we attach the new engine unconditionally, before security check