[pypy-dev] PyPy for restricted execution Python

Christopher Armstrong radeex at gmail.com
Thu Aug 19 10:15:14 CEST 2004

Thanks for the reply, Holger!

On Thu, 19 Aug 2004 09:46:32 +0200, holger krekel <hpk at trillke.net> wrote:
> Hi Christopher,
> [Christopher Armstrong Wed, Aug 18, 2004 at 06:37:58PM -0400]
> > safeEval(code, ns={'name': obj}, operations=['import', 'def', 'for', 'while'])
> Note that your 'operations' seem to be syntactical constructs and not
> operations in a bytecode or objectspace sense. [...] 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? 

Oops. In PLT-Spy, even those syntactical structures got compiled into
simple scheme function calls, so I'm used to thinking of them in that
way ;) I doubt it's *absolutely* necessary for me to totally restrict
those syntactic operations, but I think it would be cool to be able to
do that (it fits with the "absolutely inert environment as a
starting-point" principle).

> 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.

Well, yes, I'm going to have to painstakingly audit every single
function, object, or whatever I make accessible to the code to make
sure it can't give access to any *other* objects I don't want the user
to have.  But are you saying there are inherent insecurities in the
python object system that give access to things I won't want the user
to access? Hopefully PyPy will be flexible enough for me to create
simpler versions of the objects, or maybe I can write something that
wraps objects and only has accessors for certain attributes (e.g.,
__call__) to be accessed by the restricted code. Horray capabilities

> 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
> execution?

I'm self-centered ;) I think it would be a more expedient route to my
own goals to do it the way I suggested, as it looks like there's a
long way to go have PyPy be a total CPython replacement. If, otoh, you
guys make it usable in that regard by the time I want to actually
apply this, I'd be absolutely thrilled to use PyPy for all of my 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)

Thanks! I'll look into these when I'm off work.

> or ... coming to a sprint which might take place
> between 9th and 19th of October in Dublin :-)

:-( I'm in the middle of a move and a new full-time job (that has no
interest in me researching this subject ;) so I doubt I'll have the
time to go to any sprints within the next year, but who knows! Maybe I
can organize one in Australia ;-)

 Twisted | Christopher Armstrong: International Man of Twistery
  Radix  |          Release Manager,  Twisted Project
---------+            http://radix.twistedmatrix.com

More information about the Pypy-dev mailing list