[Bf-committers] Please turn off Auto Run Python Scripts by default

[Campbell Barton]

On Sat, Jun 8, 2013 at 10:02 PM, Ton Roosendaal <ton at blender.org> wrote:
> Hi Campbell,
>
> Thanks for clarifying.

I should have been a more clear in fact, (there are probably more
workaround) but basic issues with restricting module access are...

- modules are already loaded into python, so there is not a single
point you can restrict scripts by restricting import.
- modules can be accessed indirectly, eg __import__('zipfile').os
- you can access namespaces of functions, classes - which in turn can
contain modules.

>> Limiting module access is just really hard to do... <snip>
>> unless you remove the functionality altogether.
>
>
> Just in theory then: so we can make a (static linked) Python interpreter without any modules, and not allowing to load any other module or C compliled component? Just the smallest Py interpreter possible?

With CPython2.x yes (at least this was a lot more feasible), since it
could run with a single library, we did this for the Linux builds and
in fact `os` module wasn't ensured to exist but it still worked OK for
bundled scripts.

But CPython3.x has many components written in Python, and its not
clearly separated so I think we can't realistically maintain a heavily
limited CPython unless we really accept re-implementing internals in C
to make it work more like 2.x did.

Quick estimate - on loading blender, reads these files (check with strace)...
codecs.py aliases.py ascii.py utf_8.py latin_1.py io.py abc.py
_weakrefset.py site.py os.py stat.py posixpath.py genericpath.py
abc.py keyword.py heapq.py weakref.py reprlib.py copyreg.py re.py
sre_compile.py sre_parse.py sre_constants.py functools.py locale.py
imp.py machinery.py tokenize.py token.py warnings.py linecache.py

Reading over these files most would need to be kept to maintain some
compatibility (text encoding, io, tokenize... etc).

For CPython3.3 adds up to ~9526 LOC (3336 comments, 2213 blanks),
(checked with cloc),

Equivalent C code writing to the CPython-API can easily be 5x as
verbose, but lets assume not every line needs porting, I would still
think 10k - 20k lines is a optimistic estimate.
Of course its not just the line count that is a problem but that
Py/C-API code is hard to maintain and troubleshoot.

> Next step: we can make it run all our bpy commands fine? So, we can draw almost all of the UI with it, run Cyles, and we can use it for autorun scripts and even some add-ons.
>
> It would still be a "cripple" Blender from a scripter p.o.v, but for the basics of Blender usage it would be a functional tool already.

In principle what you say could work, but its still far too impractical IMHO.

> -Ton-
>
> --------------------------------------------------------
> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
> Chairman Blender Foundation - Producer Blender Institute
> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>
>
>
> On 7 Jun, 2013, at 19:29, Campbell Barton wrote:
>
>> On Fri, Jun 7, 2013 at 7:21 PM, Ton Roosendaal <ton at blender.org> wrote:
>>> Hi Campbell,
>>>
>>> I don't know enough about Python internals, so I depend on someone to help designing a sane way to handle security risks here. There must be ways we can help users?
>>
>> So far I can only see the way to help users is limited to them running
>> executable code bundled with a blend, or not. (as has been discussed)
>>
>>> Look for example at the standard UI scripts. Apart from 1 case, there's no "import os" anywhere. Same goes for essential scripts riggers or animators use.
>>>
>>> So, why not add a provision in Blender code to check on such cases. Just don't allow import of any module = safe script? In all other cases: needs to be explicitly permitted to run.
>>
>> Limiting module access is just really hard to do... this isn't about
>> being a smart-arse, its just that the way CPython works makes this
>> near impossible unless you remove the functionality altogether.
>>
>> Even if importing of modules is disabled you can use namespace tricks
>> to access modules.
>>
>> eg:
>>  os = next(iter(i for i in (1).__class__.__mro__[-1].__subclasses__()
>> if i.__name__ == '_ZipDecrypter'))._UpdateKeys.__globals__["so"[::-1]]
>>
>> Of course you can start to disable CPythons own introspection then
>> this could be disabled but Blender currently takes advantage of this
>> in some places so as Brecht says - this ends up becoming a large
>> project we need to maintain, its not just some 1-2 week project to
>> come up with a safe version of CPython.
>>
>>> Something like this would make a "trusted source" option on file loading more useful. Right now, unticking "trusted source" is almost equivalent to "disable useful features".
>>
>> With drivers yes, further though I don't think many blend files need
>> to execute code.
>>
>>> -Ton-
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell