Re: [pypy-dev] Zope2-RPython implementation help wanted..
Martijn Faassen wrote:
* try to patch up RestrictedPython by closing any new Python 2.5 related holes. This would require figuring out what these are. This has been "the plan", it has, unfortunately, met prettymuch universal derision from the PyPy guys and silence from Jim :-(
Well, the PyPy people aren't familiar with this code base. It's been proven enough technology for the last 8 years or so, so I suspect this plan is at least feasible, if hardly perfect.
Well, I dunno. Part of me is trying to get to the bottom of why the PyPy guys hate RestrictedPython so much. It seems a robust way of providing a secured (as opposed to sandboxed) pthon environment and while it requires work when the AST changes, I've yet to see someone suggest a suitable alternative, as this discussion has kindof showed ;-)
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...
Uh, Chris, that was exactly what I was talking about. You could do so, but you'd need to alter the way proxies work.
I'm not sure where you could generically plug in the un-proxying code... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Hi Chris, On Mon, Jul 28, 2008 at 11:22:11PM +0100, Chris Withers wrote:
Well, I dunno. Part of me is trying to get to the bottom of why the PyPy guys hate RestrictedPython so much.
Sorry to have given this impression so much. I can only speak for myself: "hating" is a bit too strong; genereally speaking I have little interest for the "syntactic" side of programming language or language feature implementations (like AST restrictions or manipulations), and I am more interested in solutions that work at the "semantic" level, i.e. at the level of the behavior of objects (like Zope's security proxies, PyPy's various object spaces, and (at a lower level) PyPy's sandboxing). If I have real critics about RestrictedPython it's that it's not Python at all - it's a seriously limited sublanguage. Now I'm sure there are use cases for such a thing, and unlike Python's dead rexec, I can imagine that it can be made safe with enough care. Personally I have not much interested in that (but nothing against people that do). Sorry for the over-reaction. A bientot, Armin.
Armin Rigo wrote:
feature implementations (like AST restrictions or manipulations), and I am more interested in solutions that work at the "semantic" level, i.e. at the level of the behavior of objects (like Zope's security proxies, PyPy's various object spaces, and (at a lower level) PyPy's sandboxing).
Well, this is good to hear :-)
If I have real critics about RestrictedPython it's that it's not Python at all - it's a seriously limited sublanguage.
I wonder how much of this is based on the problem I set in Vilnius? Because of the rough edges of RestrictedPython and the limited resources I had to get the challenge ready, I think the actual problem I set was a lot harder than I meant. Maciej was showing me that in the environment I specified, you couldn't even interate over a tuple of integers :-/
Now I'm sure there are use cases for such a thing,
In it's normal environment, the use case for Restricted Python is huge: - you don't need to create classes as you get all the objects you could want to manipulate from the result of the Zope environment - it's *really nice* having an environment where you can write python but where all the security checks are done for you without having to do explicit checks:
x.a Unauthorized: You are not allowed to access 'a'.
- it would be *really really nice* if such an environment prevented you chewing through excess memory and processing power, which RestrictedPython certainly doesn't offer... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (2)
-
Armin Rigo -
Chris Withers