[Bf-committers] Python sandbox

Campbell Barton ideasman42 at gmail.com
Wed Mar 17 19:54:27 CET 2010


We can ignore script installation issues or anything related to
blenders API's...
if you can run a line of python (such as a pydriver) among other evil
things you can remove the users home dir.

eg, valid one line driver which wont raise and error.
 0.0 if __import__("shutil").rmtree(__import__("os").getenv("HOME")) else 0.0

But I think we could have a more constructive discussion if we think
of a good reply to someone building a renderfarm.
(ok, only solves the problem in one case but still useful)

This might end up being that they just need to secure their systems,
but we could also include tools with blender to bake drivers in one
step so renderfarms can disable python and still render users
animations.

On Wed, Mar 17, 2010 at 7:30 PM, Richard Olsson <r at richardolsson.se> wrote:
> Hi,
>
> I'm new to the list, but wanted to add my thoughts. I've used the
> blender 2.49 py api a lot in my work as a Flash developer specialized
> at 3D, mostly writing custom exporters, and am currently working on
> the 2.50 api and scripts.
>
> I agree with Campbell that there's really no problem in allowing
> python code that's invoked by blender to utilize the full capabilities
> of python. The issue lies in executing said code without requiring the
> user to explicitly initiate it.
>
> I think that if anything, a warning should be added when new scripts
> are installed, or when add-ons are activated, stating that "By
> installing this script you allow it to execute code that may harm your
> system", or similar.
>
> The problem of course lies in operators' register() methods, for
> example, which could as far as I know contain any code, right? Maybe
> they should be swapped for a module-wide list/tuple containing the
> operator classes, avoiding the risk of unknown code being executed at
> startup.
>
>
> Please excuse any stupid comments caused by me not having followed the
> thread from the start. :)
>
>
> Cheers
> /R
>
>
>
> On 17 mar 2010, at 19.08, Campbell Barton wrote:
>
>> hehe, use lua :D, I shouldnt have suggested this at lunch today!
>> one day I'm told the API needs to be stabilized ASAP, the next,
>> suggestion to switch languages.
>> I cant take this seriously!
>>
>> LetterRip, both blender2.5 and Maya include their own python, so it
>> doesn't matter if the user has python installed or not.
>> again, the problem isnt that blender embeds python, its that we allow
>> blend files to execute python automatically, effectively making
>> opening a *.blend file as safe as running an *.exe file on windows
>> from some unknown site.
>> (automatic execution is disabled by default but renderfarms would
>> probably need to enable this to be of any use).
>>
>> but you are right, renderfarms should secure their environment,
>> sungrid did this very well. You could not even ping an external URL
>> from a render node.
>>
>> for now I'm happy to have the 'Trusted' option on load, and focus on
>> keeping blender useful rather then try apply the same rules as you
>> would with a web-plugin.
>>
>> Don't know of any developer who is interested in doing this & doubt
>> anything will change.
>>
>> On Wed, Mar 17, 2010 at 6:46 PM, Tom M <letterrip at gmail.com> wrote:
>>> Ton,
>>>
>>> on a farm blender would only have access to the folder that the
>>> admin has setup.
>>>
>>> Any computer that has python installed has the exact same security
>>> risks.
>>>
>>> These days, pretty much every computer has python preinstalled,
>>> especially one used for animation.
>>>
>>> Every animation tool has the same issue as far as i'm aware
>>>
>>> http://securitytracker.com/alerts/2009/Nov/1023228.html
>>>
>>> LetterRip
>>>
>>> On Wed, Mar 17, 2010 at 8:45 AM, Ton Roosendaal <ton at blender.org>
>>> wrote:
>>>> Hi,
>>>>
>>>> I am not talking about "make everything in Python run sandboxed".
>>>> The
>>>> target can be narrowed down to  a simpler task:
>>>>
>>>> 1) support animation scripts (drivers, constraints, fcurve mods)
>>>> 2) interface scripts
>>>> 3) basic import and export
>>>>
>>>> If '3' or even '2' is not possible, we then can try '1' even, it
>>>> might
>>>> be useful for a total-safe blender to be used on farms, or for bug
>>>> checks, etc. We should be aware that nearly every user won't ever
>>>> code
>>>> Python tools anyway.
>>>>
>>>> I also dare to challange python.org to look into this topic again.
>>>> If
>>>> we cannot provide a decent quality and reasonable safe Blender with
>>>> Python, we better ditch it and switch to Lua or so.
>>>>
>>>> -Ton-
>>>>
>>>> ------------------------------------------------------------------------
>>>> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
>>>> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The
>>>> Netherlands
>>>>
>>>> On 17 Mar, 2010, at 13:38, Martin Poirier wrote:
>>>>
>>>>>
>>>>>
>>>>> --- On Wed, 3/17/10, Campbell Barton <ideasman42 at gmail.com> wrote:
>>>>>
>>>>>> I'm not interested in this for a few reasons...
>>>>>>
>>>>>> * Its a lot of work, even python guys have trouble to do
>>>>>> this well and
>>>>>> there are way more python developers then blenders.
>>>>>
>>>>> For this exact reason, I think it's totally outside the scope of
>>>>> GSOC.
>>>>>
>>>>> Better people have tried and failed before.
>>>>>
>>>>> Martin
>>>>>
>>>>>
>>>>>
>>>>> __________________________________________________________________
>>>>> Yahoo! Canada Toolbar: Search from anywhere on the web, and
>>>>> bookmark
>>>>> your favourite sites. Download it now
>>>>> http://ca.toolbar.yahoo.com.
>>>>> _______________________________________________
>>>>> 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
>>>>
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>>
>>
>>
>> --
>> - Campbell
>> _______________________________________________
>> 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


More information about the Bf-committers mailing list