[noduerme]

Sorry... this is above my pay grade, but I still think of processes as running on a single thread, reserving memory and being mostly inviolable other than maybe sampling what they're holding at the moment. How does giving a tool the ability to analyze a thread allow it to inject code into the process as it's running? Forgive me if I'm just way behind but isn't the kernel of any modern OS supposed to prevent exactly that thing from happening?

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