[Bf-committers] Python sandbox

joe joeedh at gmail.com
Tue Mar 23 00:53:47 CET 2010


Is any of this a problem in practice? What do other applications do?
Seems to me we might be making this too complicated.  Just have a
"warning: this .blend has scripts, which can be dangerous if you don't
trust the author; enable scripts?" popup on loading .blends.

For something as complex as a digital art production package, I think
it's ok to treat .blends as if they *are* .exe's, and warn users
appropriately.

Joe

On Fri, Mar 19, 2010 at 2:36 AM, Campbell Barton <ideasman42 at gmail.com> wrote:
> Hi Leif, probably repeating myself here but I don't understand the
> rationale for some of your suggestions.
> - Secure+Updated script installation doesn't help much since blend
> files themselves can include auto-executing drivers.
> - Separate python doesn't help with security, unless its separated in
> such a way blender can run without python at all. but in that case
> they also wont get a user interface so... don't think this helps
> either unless we move the UI back into C.
>
> Agree patching python would be a pain.
>
> This is an interesting sandbox project but I dont think blender can
> use since we would need to switch trusted/untrused context a lot but
> since the topic is raised worth mentioning.
>
> http://github.com/haypo/pysandbox/tree/master/sandbox/
> It works by writing into CPythons memory with ctypes to disable
> certain aspects of python.
>
>
> On Fri, Mar 19, 2010 at 3:55 AM, Leif Andersen
> <leif.a.andersen at gmail.com> wrote:
>> As sad as it is, it seams like your axiom Jonathan, has been true.
>> Although, that is based only on empirical evidence, not an actual rigorous
>> proof.  (i.e., I would die happy if I ever found a way to make a computer be
>> secure, and work seamlessly).  Some examples of this are the previous emails
>> in this thread, about people who have had trouble with a locked down python.
>>
>> I still think though (like the first email in this thread), that it would be
>> better to keep python separate, but still make sure that it has been
>> included on the system.  We could also have a script that checks to make
>> sure it is still the latest version, in an attempt to keep it secure.  If we
>> include python directly into blender, that would add a severe amount of
>> overhead to ensure that blender keeps up with the latest build of python,
>> and even worse, if we customize it with patches, we would have to constantly
>> repatch it, work that would be better spend fixing bugs/other flaws unique
>> to blender/adding new features.Than again, on the other hand, we may have to
>> still do the same thing if we try to customize a separate python build.
>>
>> Than again, all of this is at a very hand wavy level.  And my arguments seem
>> to me consist of me waving my arms, and claiming I can fly. :)
>>
>> Anyway, thank you for the support thus far everyone.
>>
>> ~Leif Andersen
>>
>> ----------
>> So Much to Learn, Such Little Time
>> http://leifandersen.net/2010/02/03/so-much-to-learn-such-little-time/
>>
>>
>> On Thu, Mar 18, 2010 at 12:43, Mike Belanger <mikejamesbelanger at gmail.com>wrote:
>>
>>> To me its not a question of how secure your pipeline is, but how quickly
>>> you
>>> can 'bounce back' after a system failure, maliciously-motived or otherwise.
>>> Yeah, you should have a firewall, passwords, admin rights etc.  But really,
>>> the best insurance policy for studio assets is automated-backup.
>>> If anything, this sandbox thing almost sounds like it could restrict
>>> backups, or make them difficult/require consent every save.  Anything
>>> discouraging/inhibiting backup is a far bigger threat, imho.
>>>
>>> A disclaimer in front of AddOns works for me.
>>>
>>>
>>> On Wed, Mar 17, 2010 at 11:28 PM, Matt Ebb <matt at mke3.net> wrote:
>>>
>>> >
>>> > On 18/03/2010, at 15:09 , §ĥřïñïďĥï Ŗäö wrote:
>>> >
>>> > > Hi,
>>> > > This is my very first mail to this list . I am not a developer but I
>>> > > thought
>>> > > i will put my 2 cents here since I felt that this discussion is a
>>> > > waste of
>>> > > time for many reasons .
>>> > > 1: +100 for Brecth and his opinion (He is perfectly right !!)
>>> > > 2: sanboxing blender will make it unusable  in large pipelines where
>>> > > we need
>>> > > blender to be integrated with other softwares and also need to do a
>>> > > lot of
>>> > > automatic IO (this includes IO to databases and in  renderfarm too
>>> > > which can
>>> > > be used for other than just rendering out images )
>>> >
>>> > +1 to this too. Even in 2.4* we had lots of trouble at our studio with
>>> > scriptlinks, pydrivers, etc being off by default. We had problems (and
>>> > wasted hours of work) when an artist took work home, installed a
>>> > default blender from online and worked with that - getting the file
>>> > into a state that caused lots of problems when the scripts were
>>> > working as intended. This may have happened more than once too, can't
>>> > remember. Similar trouble when doing some complicated things and
>>> > sending files out to other studios who weren't familiar with Blender
>>> > and this particular issue that really doesn't affect them.
>>> >
>>> > Many people who use blender don't download and open files from
>>> > strangers on the web, and I would not like to see practical usability
>>> > hindered just to try and give people who do the impression of security.
>>> >
>>> > cheers,
>>> >
>>> > Matt
>>> >  _______________________________________________
>>> > Bf-committers mailing list
>>> > Bf-committers at blender.org
>>> > http://lists.blender.org/mailman/listinfo/bf-committers
>>> >
>>>
>>>
>>>
>>> --
>>> www.watchmike.ca
>>> _______________________________________________
>>> 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
>


More information about the Bf-committers mailing list