Ah, found that discussion again, it summarizes the sandbox issue in python pretty well, imho:
https://mail.python.org/pipermail/python-dev/2013-November/130132.html Which boils down to what Campbell says, in the end! :) On 25/05/2014 10:48, Campbell Barton wrote: > On Sun, May 25, 2014 at 6:19 PM, Chad Fraleigh <ch...@triularity.org> wrote: >> On Sun, May 25, 2014 at 12:34 AM, Campbell Barton >> <ideasma...@gmail.com>wrote: >> >> On Sat, May 24, 2014 at 7:21 AM, Chad Fraleigh <ch...@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, > Thats what pypy is, but in practice its not so useful since its not > intended to remain embedded in cpython (even if it would work somehow, > pypy's sandbox runs in a subprocess, which adds complications). > >> 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. > You could almost do this with the `ast` module, the problem is you > can't know what the script actually does until it executes. > >> 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). > Having a python interpreter written in python as you are suggesting is > possible, but I think it would be a lot of work and very slow and I > think even in this case it would be difficult to be secure unless you > restrict the drivers to arithmetic and a handful of math functions. > >> -Chad >> _______________________________________________ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers