[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