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

Bastien Montagne montagne29 at wanadoo.fr
Sun May 25 10:59:31 CEST 2014


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 <chadf at triularity.org> wrote:
>> 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,
> 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 at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
>



More information about the Bf-committers mailing list