On Sat, Aug 14, 2010 at 8:07 PM, Stephen Hansen <me+list/pyt...@ixokai.io> wrote: > On 8/14/10 5:09 PM, Steven D'Aprano wrote: >>> My worst case >>> fall-back plan is to embed /another/ language (be it Lua or JavaScript >>> through V8) and offer it a very limited environment. But I don't want to >>> do that (and considering I solved the while True: pass problem last >>> night, I'm pretty sure I won't decide to). >> >> I assume you mean you've solved the problem of DOS attacks from users >> running infinite loops. How did you do that? > > Since I only have to run this on Unix-isms, I'm using alarm()/signal(). > The C code takes the hash of the source code that's going to be executed > and marks it, then sets an alarm and executes the code (though its > usually been compiled into a code object). > > There's no code which would -ever- in this situation take longer then 2 > seconds to run (and that's extremely generous), but the alarm is 5: if > the code doesn't return and cancel the alarm by then, I know the code is > functionally broken. > > So, the signal handler records the hash of the code that failed -- it'll > never be tried again -- logs an error message, and restarts the whole > process (which happens seamlessly with virtually no user interruption, > but this system is not architected in a way where its readily able to > resume operation in the event of a signal interrupt). > > This isn't perfect: infinite loops it kills, but things like [0] * > 10^^100 crash head first into the machine and bring it to a crawl. I > haven't figured out a strategy for trying to address that yet, and > ultimately, I may not find one. That's okay: perfection isn't my goal, > infinite loops are easy enough to do on accident that halting them is > important.
cpulimit or a cgroups container can both be easy solutions here, depending on your exact needs. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
