I Spy untrusted code
I've been hacking on PLT Spy recently. It's an implementation of Python that uses PLT Scheme's runtime.
Spy works by taking advantage of the CPython runtime. Previously the developers tried to implement Python from the ground up, but now they're taking an approach that will be much easier to implement, and make it *much* more useful. The core Python C APIs (like memory management, code evaluation, module creation, and so on) will be reimplemented to use the PLT/Spy runtime. Then we can use the C code straight from Python; the built-in types, the built-in extension modules, and, of course, third party C extensions all will work without modification (currently, we have a bunch of hacks in place in the CPython code, but those will be unnecessary once the core APIs are more fully implemented).
So, we have compatibility with damn near all existing Python code. That's great. The community probably wants to know what it's actually *useful* for, though. The whole reason I'm contributing to Spy is for restricted execution in the context of virtual worlds. Restricted execution is pretty much impossible with the current Python implementation; it's simply not flexible enough, and would require rewriting portions of it (which is what we're doing :).
The most important bit in implementing restricted execution is being able to have a whitelist of what some code can access (i.e., capabilities). This is really simple to facilitate from a language-implementation perspective, if you're thinking about it while you're writing the implementation. You just have to parameterize the initial namespace that some code can access, and make sure no basic operations allow it to access other objects that aren't in the whitelist.
Much harder is actually figuring out what to put in the whitelist, and whether or not the things you're putting in it will allow code to compromise your system. But that's not relevant from Spy's perspective; it's up to the programmer to design secure APIs.
PLT doesn't really offer anything, per se, to help us with the aforementioned restricted execution support (whitelists). Simply having a flexible implementation of the language, in a high-level language, makes it easy. It does, however, offer some extra goodies that might help a lot in other areas of restricted execution. There are things called 'custodians' which can limit a thread's memory usage to a particular number of bytes; so some code that's restricted won't be able to infinitely append to a list in order to make your program run out of memory. It also has some form of CPU restriction via 'thread groups', but it doesn't seem like it's very fine-grained. I'd like to be able to say "after N CPU-seconds, kill this thread". If there are no built-in tools for that, though, it seems feasible to implement on my own anyway.
Since we're giving access to a bunch of semi-arbitrary C code (CPython's code), I'm going to have to be careful about giving access to things which may allocate memory or use CPU unboundedly.
I'm not sure how excited the general Python community would be about having this implementation, in the context of its restricted execution support. I'm not *too* concerned about it, since it'll be useful to me even if nobody else uses it, but having a community is an incredibly useful thing.
