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