This is a pretty long article that should have started with the last section:
> So what?
> What’s the point of this whole thing, can’t you just do os.system(...)? Well, yes.
> Given that you need to be able to execute arbitary Python code in the first place, this exploit won’t be useful in most settings. However, it may be useful in Python interpreters which are attempting to sandbox your code, through restricting imports or use of Audit Hooks, for example. This exploit doesn’t use any imports and doesn’t create any code objects, which will fire import and code.__new__ hooks, respectively. My exploit will only trigger a builtin.__id__ hook event, which is much more likely to be permitted.
I was wondering how the "io" module was involved when the exploit claimed to not use any import. The answer is "io = open.__self__" [1]. Allowing "open()" would be an oversight if a sandbox intends to block "io".
> So what?
> What’s the point of this whole thing, can’t you just do os.system(...)? Well, yes.
> Given that you need to be able to execute arbitary Python code in the first place, this exploit won’t be useful in most settings. However, it may be useful in Python interpreters which are attempting to sandbox your code, through restricting imports or use of Audit Hooks, for example. This exploit doesn’t use any imports and doesn’t create any code objects, which will fire import and code.__new__ hooks, respectively. My exploit will only trigger a builtin.__id__ hook event, which is much more likely to be permitted.