[pypy-dev] Zope2-RPython implementation help wanted..

[holger krekel]

Hi Chris, Martijn, all, 

On Fri, Jul 25, 2008 at 17:15 +0100, Chris Withers wrote:
> Hi All,
> 
> Martijn Faassen wrote:
> > I think it's unlikely path to try to make pypy-sandbox, a special
> > version of PyPy, work in a Zope 2 context right now.
> 
> I'm inclined to agree, but I'd avoid writing it off until the PyPy guys 
> have agreed. I would be surprised if they can pull something out of 
> their box of tricks here, we may just need to find the right way to 
> phrase the problem ;-)
>
> At the very least, we should be trying to find the "right" way for 
> realms beyond Zope 2, which it sounds like both myself and Stefan are 
> encountering...

Here are some of my thoughts on the topic - Armin, who did most
of the current sandbox impl is on vacation like are others btw. 
There is not too much of explicit "pypy group-think" on the topic yet :) 

Basically I see packaging and conceptual concerns. For the first,
i think we can assume that we can have a

      easy_install pypy-python-sandbox 

which would install a nice sandboxed interpreter executable that 
you could drive from an application via some nice API.  You could 
control what the sandbox sees as files, and its cpu and ram 
usage. This basically is doable today. 

What the sandboxed code currently could't easily do is interact
with app objects from the driving process.  However, I think we
could provide means to represent app objects within the sandboxed 
program and let the parent/app process see and decide about 
operation on them.  (see e.g. transparent proxies here 
http://codespeak.net/pypy/dist/pypy/doc/objspace-proxies.html#transparent-proxies 
for some existing tech). 

This might resemble what Martijn proposed by reimplementing
restricted python on top of security proxies.  However, you'd
probably need to care a lot less regarding controling code
paths that lead to IO like crafting a __builtins__ that
doesn't have open etc.  You could also mindlessly allow the
sandboxed code to import python modules, including ones that
your app provides for manipulations because you can be sure
that no IO is going to escape.  And for this you wouldn't need
to mess with __import__ but could allow file access to .py
files from the standard lib directory plus ones from app
directories.  

I think the remaining crucial point is how to conveniently 
define and implement a python object protocol for the proxy 
interaction layer.  This is a two-sided question: what is 
convenient for the driving app and what is safely doable 
for our generated pypy-sandbox interpreter. 

best, 

holger

-- 
collaborative expert contracting: http://merlinux.eu 
PyPy  Python/Compiler tool chain: http://codespeak.net/pypy 
pylib py.test/greenlets/svn APIs: http://pylib.org