Tricking a higher-privileged bit of code into doing the bidding of a lower-privileged app is really common in the history of nasty security exploits. Windows Ke

Tricking a higher-privileged bit of code into doing the bidding of a lower-privileged app is really common in the history of nasty security exploits. Windows Kernel developers and Web Browser developers have both spent over a decade systematically eliminating scenarios where this can happen, whether it's forging WM_TIMER messages or attempting to get around javascript API origin/trust restrictions. "I convinced this other program to dump an executable shell script onto disk for me so I could run it without a prompt" is a textbook escalation of privilege vulnerability, and being able to do it with a common app like TextEdit or BBEdit is pretty serious. One solution is for the outermost caller's credentials to apply all the way down the chain. This is common in Windows and in web browsers - web browsers basically track whether the current chain of actions originated from user input or not so that they can prevent websites from silently doing nasty stuff without user consent. At this point browsers actually track that consent data across asynchronous computation so everything will work. I personally don't think an app with 'create shell script' permissions should be able to be controlled by Joe's Random Unprivileged App, but that's just me. Windows certainly doesn't allow low integrity apps to communicate with arbitrary high integrity apps. Introducing that restriction is an essential security improvement.