[pypy-dev] Zope2-RPython implementation help wanted..
holger at merlinux.eu
Fri Jul 25 20:46:09 CEST 2008
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
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
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
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
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.
collaborative expert contracting: http://merlinux.eu
PyPy Python/Compiler tool chain: http://codespeak.net/pypy
pylib py.test/greenlets/svn APIs: http://pylib.org
More information about the Pypy-dev