On 4/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > 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).
Anyone have any other links to stuff, especially research papers? My dissertation topic is adding Python into HTML to be at the same usage level as JavaScript (have not started work on it yet; just decided on the topic this past week). This means sandboxing Python like JavaScript is so that Python code doesn't hurt the browser or the system it is running on. Won't cover C code, but it should still be at least a good starting point. -Brett _______________________________________________ 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
