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 -- http://mail.python.org/mailman/listinfo/python-list
