[pypy-dev] Zope2-RPython implementation help wanted..

[Chris Withers]

holger krekel wrote:
>> - something that behaves like a python function
>> - can be pickled
> 
> this is basically about storing user-provided scripts 
> in the zodb, right? 

...or relational database, or, etc ;-)

>> - prevents people stripping security proxies from objects that are  
>> passed in to the function
> 
> hum, pypy-sandbox currently virtualizes at a low level 
> (access to the Operating Systems files, io, etc.) and 
> provides a *very* trustable way of running untrusted code.   

Right, which is exactly what we want ;-)
The security proxying is handled by a different method entirely.
(The proxy objects are c extensions and prevent accessing attributes 
based on a pluggable set of rules)
However, with access to unrestricted imports, all you'd need to do is 
import the unwrap method from the proxy wrapping module and you'd be fre 
of the jail ;-)

> For providing higher and python level virtualization more work
> is needed so it might indeed not directly fit some use cases
> that RestrictedPython tries to satisfy.  I am interested in
> this as are others, i think.  Could you or someone else point to 
> some concrete usages and use cases of the current RestrictedPython? 

- Download and install Zope 2.11.1.
- Add a "Script (Python)" using the Zope management interface.
- Write some python code or look at the default python code that starts 
off in the python script.

The use case is basically threefold:

- general distrust of code authored through a web browser
   (what if someone managed to break in somehow and insert source code 
for a PythonSript (the things Zope calls "Script (Python)" in its 
management interface), etc)

- provide an environment where objects that shouldn't be accessible by a 
particular user are filtered by the environment and where objects can 
also prevent their attributes from being written to or read.
(the user here doesn't write code, they are running other code... as a 
programmer, rather than having to write security checks all the time 
yourself, the environment does it for you)

- allow customers to write scripts where they do so in an environment 
where they can't access things that they shouldn't be able to, be it 
data, or functions like os.system, etc.

There's also a "nice to have" rather than a requirement of providing an 
environment where code can be safely run without it accidentally 
consuming all memory or processing resources on a machine.

>> - prevents people importing things they shouldn't
>> - prevents people from getting hold of un-security-proxies-objects
>> - executes as fast as possible
>> - each function plays in its own sandbox and can be called many many  
>> times, often simultaneously in different threads
>> - limits the amount of memory and processor they can hog (nice to have)
> 
> the rest, i think, is quite doable, particularly 
> limiting RAM/CPU resources. 

cool :-)

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
            - http://www.simplistix.co.uk