Replacement for rexec/Bastion?

[Michael Chermside]

Michael Chermside writes:
> Consider, for instance,
> this code:
> 
>      x = 1000000**1000000
> 
> I guarantee it'll lock up your python interpreter for a fairly long
> time. And it executes in C so there's no possible way you can trap
> it.

Colin Coghill (SFive) replies:
> I think I resolved this kind of thing a while ago by using seperate 
> processes. The user-code one and the actual application. If the 
> user-code one stops responding for some tunable time, it gets 
> kill -KILL'ed and restarted from the last checkpoint minus the 
> offending code.
> And for resource limits, ulimit seems to work fine on the several
> systems I've tried.
> 
> Yes, this is messy UNIXy stuff, and loses portability, which is bad, 
> but it at least seems to make it possible to do this stuff.

Great! If you are willing to run the untrusted code in a separate
process and fall back on the OS to do the restricting, it _is_ 
actually capable of restricting what code can perform, in a way that
Python simply can't match. You can use ulimit and chroot to restrict
what the untrusted code may do. Then there's no particular need to
use ANY special restricted execution support in Python. Use Python's
easy-to-use support for interprocess communication to make a
simple server which runs untrusted code bits, but which is itself
run in a separate process inside a ulimit / chroot / 
user-with-limited-permissions jail, and which is killed and restarted
whenever it gets in trouble.

If you DO wind up going this route, I'm guessing that the code
to launch an untrusted-code-runner in a separate process would be
quite popular if it were released back to the Python community,
judging from the number of times this question gets raised.

-- Michael Chermside