On Oct 24, 2008, at 10:01 AM, Chris Withers wrote:
> Jim Fulton wrote:
>> 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.
> Isn't there a way we could change the AST manipulation such that we
> start with nothing and only allow opcodes as and when they're added
> to the RestrictedPython implementation?
No. we're starting with an existing program written in a Python script
or expression. We then have to sanitize it.
>> The Zope 3 security proxy approach is much better
> I agree, but it doesn't solve all the problems. My understanding of
> the original set of requirements which we're trying to solve here
> was basically that of Python Scripts: to allow python code to be
> written through the web. This means:
> - restricting access to atributes of objects
> (security proxies give us this, right?)
> - restricting access to features of the language such as imports such
> that unsafe things such as stripping security proxies can't be done.
> (security proxies *don't* give us this, right?)
Yes, they do, as long as all builtins, including __import__, are
wrapped and as long as you only include safe builtins.
> ...and some nice to haves:
> - restricting memory used by executing the code
> - restricting cpu used by executing the code
These require deep changes to the interpreter.
> I know RestrictedPython doesn't support these last two very well,
> but there are hints that it would have liked to if it could.
It can't support these at all.
>> 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.
> Who is then? ;-)
In the Python community, I;d say we are. Beyond that, I don't know.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -