[korfuri]

A lot of legitimate debugging features involve actually modifying the code of the target. This is a common way of setting breakpoints: you replace the instruction at the given address with a trap instruction that will hand control back to the debugger. Then the debugger puts the original instruction back and resumes the target's execution.

And since the two processes already run as the same user, in the original model there's nothing the target can do that the debugger cannot also do, so this was not a privilege escalation path.

[noduerme]

If you're debugging as the same user that makes sense because the debugger is supervising the code. (the debugger can't for example halt other processes besides the code it's supervising). But how can some other random process even with the same user just inject itself into running compiled code without somehow having the ability to rewrite memory? [edit: memory that has already been allocated by the kernel for the thread it's trying to interfere with]

[hmage]

The difference between debugger and non-debugger in 80's unix is... none, besides calling ptrace().

I called ptrace() on your pid, therefore I am your debugger now.