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

[holger krekel]

Hey Chris, all,

On Thu, Jul 17, 2008 at 08:43 +0100, Chris Withers wrote:
> holger krekel wrote:
>> names are confusing here.  
>
> Indeed, I think Ranjith can be forgiven for getting confused given the  
> proliferation of similar names in this area ;-)
>
> For clarity, shall we agree to refer to things as:
>
> RestrictedPython - the current Zope 2 implementation found at  
> http://pypi.python.org/pypi/RestrictedPython
>
> Sandboxing - the technique of getting a secure and restricted python  
> environment running.
>
> RPython - some special in the pypy world ;-)

"some special", aha :) i just added a FAQ entry: 

http://codespeak.net/pypy/dist/pypy/doc/faq.html#does-rpython-have-anything-to-do-with-zope-s-restricted-python

>> Indeed, PyPy provides a robust way of sandboxing its Python 
>> Interpreter, see 
>>
>>     http://codespeak.net/pypy/dist/pypy/doc/sandbox.html
>
> Indeed, although as it is, I'm not sure how good a fit it is.
>
>> I am not sure how well this fits in your "porting zope2 to
>> python2.5" project - but to me it looks like a good idea to go for 
>> using pypy-sandbox in the future instead of trying to get Zope2's 
>> "RestrictedPython" secure and ported to 2.5. 
>
> Well, the rough feature request list is:
>
> - something that behaves like a python function
> - can be pickled

this is basically about storing user-provided scripts 
in the zodb, right? 

> - 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.   

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? 

> - 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. 

> I'm sure others will pitch in if I've forgotten anything...

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