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

[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.

> But security_ptrace_traceme() is strange anyway, I never understood it.
> It is called under tasklist_lock, but I can't see how this lock can
> help. ->parent can change its creds right after the check.

It may well just be that the LSM check was originally inserted in a place
where tasklist_lock was held for incidental reasons.  You should check with
the security folks about what really matters for that.

> Somehow with the last 2 patches the kernel survives after make xcheck.

:-)  I bet we can still break it.

> A lot of warning from ptrace_resumed()->WARN_ON(task->last_siginfo != info)

That was around for a long time and I never figured it out.  But it almost
certainly indicates some misbehavior would occur in some usage patterns,
even if not ones we have figured out specifically how to test.

> I am ignoring ptrace_report_clone() for now. I think it should not
> rely on tracehook_finish_clone/tracehook_report_clone(). Instead it
> should do all work itself, we have PF_STARTING. 

Right.  This was the main reason (only reason, really) for the special
UTRACE_ATTACH_CREATE ordering guarantee that necessitates PF_STARTING.
(If it helps, we can also reconsider how that logic is specified in the
utrace API and/or how we implement it.)  In fact, it's the main reason
for being able to use UTRACE_ATTACH_MATCH_OPS|UTRACE_ATTACH_EXCLUSIVE at
all.

> 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 the special priority
report_clone gets for UTRACE_ATTACH_CREATE.  It's more like PTRACE_ATTACH
in that it runs in the parent context (inside clone/fork), whereas
PTRACE_TRACEME may have fewer issues to worry about because it runs in
the tracee context.


Thanks,
Roland