On Sat, Jun 8, 2013 at 10:02 PM, Ton Roosendaal <t...@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 - t...@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 <t...@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@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
--
- Campbell
_______________________________________________
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
