[pypy-dev] PyPy for restricted execution Python

holger krekel hpk at trillke.net
Thu Aug 19 09:46:32 CEST 2004

Hi Christopher, 

[Christopher Armstrong Wed, Aug 18, 2004 at 06:37:58PM -0400]
> I want to have a function along these lines:
> safeEval(code, ns={'name': obj}, operations=['import', 'def', 'for', 'while'])
> It'll execute 'code', with only access to the names in 'ns' dict, and
> only the operations listed in the 'operations' list. This function
> would be called from a regular CPython interpreter, and safeEval would
> be an interface to PyPy.

Note that your 'operations' seem to be syntactical constructs and not 
operations in a bytecode or objectspace sense.  If you really want to
forbid certain syntactical constructs you probably need to look
at the abstract syntax tree of the code string. Are you sure
you want to restrict something on the syntactical level?  Or
do you rather need to e.g. restrict what can be imported? The
latter might be done by providing your own bytecode 
and/or builtin-implementations within PyPy. 

And when you expose the above 'obj' what do you expect with
respect to attribute-accesses?  You can go a long way just 
having access to a plain python object. 

> My end goal is to have potentially hundreds of *totally* untrusted
> scripts running concurrently; they shouldn't be able to stomp on each
> other or on the "main" application code. CPU and memory restriction
> are a big issue, but I'm only concerned with namespace and operation
> restriction at the moment. The core of any restricted system needs to
> be able to start code in an absolutely empty environment, not allowing
> anything at all. Then I can add operations and functions necessary for
> my application after I do the Hard Work of auditing each one ;)

This would be an interesting one-week sprint topic at some point :-) 
It seems the basic approaches are controling name
visibility and/or controling object accesses. Both require 
careful thinking about all the objects reachable through 
attribute accesses. 

Maybe other can chime in here so that we can think together
about what the best approach for a restricted Python within 
PyPy might be.  So far it hasn't been anybodies "special interest". 

> This is the same reason I was recently working (well, somewhat.. ;) on
> PLT-Spy[1], an implementation of Python on PLT-Scheme. It compiled the
> Python to Scheme code which has calls to a Python runtime implemented
> for PLT. The Python runtime does 99% of its work by calling out to
> libpython, i.e., CPython. So, this let me have my cake and eat it too:
> I could take advantage of PLT's awesome restricted-execution support,
> *and* I could use CPython without reimplementing the whole runtime.
> But it wasn't _that_ simple: we have to modify some fundamental parts
> of CPython to interoperate with PLT. The garbage collection and
> namespace functions, in particular. I'm hoping I can entirely avoid C
> code by using PyPy and still be able to use the stock Python runtime.

PyPy should generally allow you to avoid C. 

But I am not sure you have a misconception here.  While our
intermediate goal is to generate code runnable on top of the
CPython runtime PyPy aims to be a self-contained
implementation.  Do you need the stock CPython runtime for
anything in particular or would you be happy with a
self-contained Python implementation allowing restricted
> PyPy is confusing to me so far, though. I've worked with several
> implementations of small languages, including a tiny lisp meant for
> restricted execution, and even an implementation of Python (PLT-Spy).
> I can't seem to get my brain integrated with the PyPy codebase, yet,
> but I'm not sure where to start. So, given that explanation of my
> goal, where should I start? What might I have to change in PyPy? How
> can I get an analog of pypy.interpreter.main.run_string that lets me
> restrict what's available to the code?

Possible starting points include the builtin module (modules/__builtin__*.py), 
the parser (see my first para, though), or the bytecode implementations 
(interpreter/pyopcode.py) or ... coming to a sprint which might take place 
between 9th and 19th of October in Dublin :-) 



More information about the Pypy-dev mailing list