Re: [pypy-dev] Zope2-RPython implementation help wanted..
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...
This has been "the plan", it has, unfortunately, met prettymuch universal derision from the PyPy guys and silence from Jim :-(
* reimplement RestrictedPython using zope 3 security proxies
This is only half the problem, though...
Why would they cause havoc? They'd only result from stuff in a python script calling back into Zope, surely? It's a shame we can't form a better "blood/brain barrier" that proxies on the way in and de-proxies on the way out...
The hope of this strategy is that it's easier to maintain in the face of new Python versions than the current RestrictedPython approach.
Right, but there's still the language problems, of which importing is the most serious, but I'm sure there are more lurking there... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Hi Chris, Martijn, all, On Fri, Jul 25, 2008 at 17:15 +0100, Chris Withers wrote:
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-pr... 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
Hi Chris, Martijn, all, On Fri, Jul 25, 2008 at 17:15 +0100, Chris Withers wrote:
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-pr... 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
participants (2)
-
Chris Withers -
holger krekel