[Python-3000] Will we have a true restricted exec environment for python-3000?

[Brett Cannon]

On 4/14/06, Nick Coghlan <ncoghlan at gmail.com> 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