[Bf-committers] Do drivers have to be blocked as python scripts?

[Chad Fraleigh]

On Sun, May 25, 2014 at 12:34 AM, Campbell Barton <ideasman42 at gmail.com>wrote:

On Sat, May 24, 2014 at 7:21 AM, Chad Fraleigh <chadf at triularity.org> wrote:
> > Just wondering.. has anyone out there wrote a python interpreter *in*
> > python that has security/sandbox functionality/hooks? Then it could offer
> > the option (as another user selectable security level) of "secure but
> > slow", which might be adequate for simple or non-intensively called
> > scripts. Since it would be a python script itself, it would/should be
> > portable across the underlying implementation.
> >
> > Depending on the features of such a hypothetical library/module, if the
> > parsed expression tree can be checked and determined to be simple (i.e.
> no
> > field assignments, no arbitrary function calls, etc..) and known safe, it
> > could be then be directly eval'd by the real python and not just
> emulated.
> > Essentially a variation of one of the ideas previously mentioned in this
> > thread.
> >
> >
> > -Chad
>
> Someone has done just this:
>
>  http://pypy.org
>
>
> Which also provides a sand-boxed execution environment to prevent
> scripts doing things you may want to prevent:
>
>  http://pypy.readthedocs.org/en/latest/sandbox.html
>
>
But that seems to be just another implementation of python at the binary
library level. What I meant was a python language interpreter that is
written purely in python code itself, which will run on top of the existing
python runtime that blender uses (not replace it). It would need to only
support the parsing of scripts, access checking/hooks, and the minimum
execution of the language itself. Since it would run on top of the real
python, any standard modules needed would be done by delegating it to the
underlying ones (so it would have a very minimalistic runtime).


-Chad