On Oct 21, 2008, at 8:29 AM, Chris Withers wrote:
Sidnei da Silva wrote:
I always was under the impression that Jim feared the code and the required security audit was perceived as a major painful undertaking.
That was my perception too. But after looking at the code it is really not bad at all.
The PyPy guys, who seem to be the authority on this kind of stuff, always shake their heads in woe at the mention of RestrictedPython.
As well they should. Relying on it is a lot of work and brittle.
I've tried to understand what they perceive the "real problems" with it to be but haven't managed to extract anything meaningful :-(
The problem is that it it starts with an environment in which things are allowed by default, and takes things away. This means that if anything is forgotten, then you end up with holes. A better approach is to start with something that lets you do nothing and add capabilities that are known to be safe. This is why some folks get all excited about capability-based security. The Zope 3 security proxy approach is much better than relying solely on restricted Python, because, as with a capability-based approach, it prevents what isn't explicitly allowed. It does this (for the most part) without having to do code manipulation. It still uses restricted Python do deal in a narrow way with basic objects, like strings and numbers, that are unproxied. It's use of restricted Python is so narrow that it is far less problematic. It would be really great if Zope 2 would switch to security proxies, although the transition is likely to be painful. I'm not sure that the PyPy guys are really authorities on the sorts of problems we're trying to address, although there is some overlap. If I remember correctly, they are just focussed on protecting the system from untrusted scripts. Our problem is harder because we also want to protect objects available to the scripts. Jim -- Jim Fulton Zope Corporation