Ivan Krstic wrote: > Nick Coghlan wrote: >> This is why I think the first step in a solid Python restricted >> execution framework isn't an implementation activity but a >> research/scoping activity, looking at the various systems already out >> there, and the various trade-offs involved in each. > > This might be a good point to invite Ben Laurie (of Apache-SSL fame) to > jump into the conversation. He researched restricted Python execution > when working on what eventually became CaPerl: > > http://www.links.org/?p=28 > > See also the responses to Ted Leung's blog post about this > (http://www.sauria.com/blog/2005/Nov/27), with comments by Phillip Eby > and Ian.
Ah, interesting. Especially this: http://svn.zope.org/Zope3/trunk/src/zope/security/untrustedinterpreter.txt?view=auto So one avenue definitely worth investigating would be extracting Zope's untrusted code execution security mechanisms into a form that can be used independently of the rest of Zope. That would probably be a lot nicer than having to start from scratch, but there's the question of how tightly integrated that mechanism is with the rest of Zope's infrastructure. It may prove more effective to build something *modelled* on Zope's system, without actually reusing their code. I'll also note the similarities between this model and what Ian and I were suggesting - the restricted subinterpreter would contain only 'safe' builtins, with any unsafe operations being proxied back to the original application (which could then allow or deny them as it saw fit). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
