> 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