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