Simple Python Sandbox

[geremy condra]

On Sat, Aug 14, 2010 at 8:07 PM, Stephen Hansen
<me+list/python at 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