Thanks very much for your report. I'm sorry there's been such a delay before I could follow it up. > ptrace_attach() does permissions check _after_ actual attaching. Given > that utrace_attach is quite non-trivial operation there is no way such > ordering should be allowed -- the following program should crash the box > in less than second. utrace_attach is intended to be a reasonably cheap operation. Anyway, we are never too concerned about the performance of an error case. The reason ptrace_attach does utrace_attach first is to preserve the order of error diagnoses. That is, to avoid calling ptrace_may_attach at all if ptrace_attach is going to fail because someone is already attached. This keeps it consistent with vanilla ptrace. In particular, security_ptrace should not be called when ptrace_attach fails for the "already attached" or "already dead" errors. Whether the call succeeds or fails, it may trigger security logging or whatnot that should not be done for these cases. The utrace_attach, utrace_detach sequence in a failing ptrace_attach is slightly costly. But it a) shouldn't be too bad and b) is just an error case. Moreover, it always ought to work without crashes whether it's a good idea or not! Your patch fixes what's not itself a problem, and thereby masks the actual problem that needs fixing. Fortunately, I can now reproduce this problem quickly using your test case. This is the utrace_detach bug you previously identified in http://lkml.org/lkml/2007/5/8/244, which is already #1 on the wiki utrace/bugs list. I wasn't using a good test case for it before, but this case hits it. I think some reasonable fixes are straightforward, and now I can try one and test it with some confidence using this test case. Thanks, Roland