limited python virtual machine
Jack Diederich
jack at performancedrivers.com
Sun Jan 30 09:49:19 EST 2005
On Sun, Jan 30, 2005 at 11:59:39AM +1000, Nick Coghlan wrote:
> Alex Martelli wrote:
> >It didn't seem to me that Steven's question was so restricted; and since
> >he thanked me for my answer (which of course is probably inapplicable to
> >some custom interpreter that's not written yet) it appears to me that my
> >interpretation of his question was correct, and my answer useful to him.
>
> Yes, I'd stopped following the thread for a bit, and the discussion had
> moved further afield than I realised :)
>
> >If you _can_ execute (whatever) in a separate process, then an approach
> >based on BSD's "jail" or equivalent features of other OS's may be able
> >to give you all you need, without needing other restrictions to be coded
> >in the interpreter (or whatever else you run in that process).
>
> I think that's where these discussion have historically ended. . . making a
> Python-specific sandbox gets complicated enough that it ends up making more
> sense to just use an OS-based sandbox that lets you execute arbitrary
> binaries relatively safely.
>
> The last suggestion I recall along these lines was chroot() plus a
> monitoring daemon that killed the relevant subprocess if it started
> consuming too much memory or looked like it had got stuck in an infinite
> loop.
>
The Xen virtual server[1] was recently metnioned on slashdot[2].
It is more lightweight and faster than full scale machine emulators because
it uses a modified system kernel (so it only works on *nixes it has been
ported to). You can set the virtual memory of each instance to keep
programs from eating the world. I don't know about CPU, you might still
have to monitor & kill instances that peg the CPU.
If anyone does this, a HOWTO would be appreciated!
-Jack
More information about the Python-list
mailing list