Restricted Execution

[jonathan allen booth]

I was looking at embedding Python where it will get user-input code,
which may be malicious.

Obviously I'm going to be using rexec to run it, to take care of part of
that problem, but that still leaves the problem of non-terminating code
open -- someone passing in a while 1: with no break or other exit
mechanism.

Since rexec can't help here (according to the docs), I perused the code
and came up with two options:

1. It looks like profiling support may be able to simulate this, written
   in python code (hacked profiling), but at a preformance penalty.

2. Of course instruction count limiting can always be hacked into the
   interpreter. Perusing the source, I saw a recursion depth check (which I
   don't think is settable dynamically in code -- it'd be nice if it was)
   in ceval.c which could have a sister instruction count check added
   alongside it (but that only makes sense if it would be dynamically
   settable, so you could turn off the limit when you're running known-safe
   code).

I'd prefer 1 even if it has a preformance penalty, if it isn't likely
that the changes in 2 would become part of the main distro (don't want
to have to tell people to get python, apply this patch, compile it and
so fourth).

Is there already a solution out there I've overlooked? Any comments on
either of the above solutions for this problem (I want to avoid having
to fork a whole new process or use threads if I can)?

Thanks,

-- 
Jonathan A. Booth				kamikaze at N0$PAMimsa.edu
http://www.N0$PAMimsa.edu/~kamikaze		jbooth at N0$PAMuiuc.edu
Remove NOSPAM from hostnames. Unsolicited commercial e-mail: access denied