[Zope-dev] Re: RestrtrictedPython vs zope.security.untrustedpython

Martijn Faassen faassen at startifact.com
Tue Nov 20 05:19:29 EST 2007


Philipp von Weitershausen wrote:
> On 20 Nov 2007, at 00:15 , Chris Withers wrote:
>> Philipp von Weitershausen wrote:
>>> On 19 Nov 2007, at 20:26 , Chris Withers wrote:
>>>>>> So, I'm guessing RestrictedPython is the one to aim for?
>>>>> No idea what you need...
>>>>
>>>> http://mail.python.org/pipermail/python-list/2007-November/466438.html
>>> It seems like zope.security does exactly what you need (e.g. user 
>>> code shouldn't have to import anything as long as you pass proxied 
>>> objects).
>>
>> Indeed, but how do you prevent importing and insecure builtins like 
>> "open" without RestrictedPython?
> 
> Well, they can only use the builtins you give them, right? And the 
> 'import' statement can be influenced with import hooks, AFAIK. I don't 
> knwo this for sure, though, so maybe you do need RestrictedPython after 
> all.

One bit that might be problematic is 'proxy leaking'. I imagine if you 
use this you're going to leak proxied objects into the rest of your 
system whenever you make a call into your system.

Traditional Zope 2 doesn't work that way: as soon as you make a call 
from your Python script, the underlying code that is being called is 
trusted. No proxies anywhere (well, except the ubiquitous acquisition 
proxies..).

I don't know whether this could be a problem for your use case. You 
could solve it by using a special kind of proxy that proxies everything 
that you receive *into* the Python script from return values but removes 
the proxy from any arguments you pass in when you make a call.

Regards,

Martijn



More information about the Zope-Dev mailing list