[pypy-dev] PyPy for restricted execution Python

[holger krekel]

Hi Christopher, 

[Christopher Armstrong Thu, Aug 19, 2004 at 04:15:14AM -0400]
> On Thu, 19 Aug 2004 09:46:32 +0200, holger krekel <hpk at trillke.net> wrote:
> > [Christopher Armstrong Wed, Aug 18, 2004 at 06:37:58PM -0400]
> > >
> > > safeEval(code, ns={'name': obj}, operations=['import', 'def', 'for', 'while'])
> > 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
> :-)

I think the challenge is to find an easy scheme for doing
restricted execution in Python.  So far it seems that there is
a lot of complexity involved.

The specific goal of disallowing File/IO operations and
restricting memory/cpu usage seems interesting enough to look
for a specific solution and not for some general scheme of
dis/allowing object accesses.  

One basic idea is to be able to allow/disallow the usage of code
objects according to in which module they live.  We then
wouldn't disallow "import socket" or any other import which
leads to importing socket but we would say "when i execute
this function f() here i don't want to execute code that comes
from the module 'socket'".  (Of course you can also have a positive
list of allowed modules etc.pp.). 

So we would have to keep exact references where code
originates/was build (mostly 'co_filename')  and we would need
the interpreter to check for these references and some
policies at certain points.  This seems easy enough to do in
PyPy.  

> > 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
> :-)

We'll see.  In some ways PyPy is not that far away from being
self-contained.  FYI, we really have only been hacking for ca.
7 sprint weeks so far plus some extra weeks spent by a few
developers.  
 
> > 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 ;-)

Uh oh, i see.  Well then good luck at your new job, anyway. It's not
even related to Twisted? 

cheers, 

    Holger