Hi, I think you give up too easily here. :) For example, we could also make a bpy.os module, and mark scripts that use this as 'trusted'. Scripts using the os.module itself then require a user to explicitly run it, or being embedded in a file marked trusted (own files etc).
This is not to forbid using os module, it's to not make such scripts run automatic. The main issue would be first to sanitize our non-python writing code, make sure this goes more secured and controlled. Once that's in place, scripters can use that as well, and get free support for the features we use in Blender C code all over as well. -Ton- -------------------------------------------------------- Ton Roosendaal - [email protected] - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands On 5 Jun, 2013, at 19:55, Campbell Barton wrote: > Hacked os module isn't really an option, Python uses this for its > internal operations all over the place - a lot of python modules are > written in Python so these would break. > > In python3.3 module dir... > find -name "*.py" | xargs grep "\bos\." | wc -l > --> 7833 > > Attempting to let Python do its own thing but sandbox Blender scripts > also cant work well, > > In the BGE we did have some basic security (disable some modules & > open()... iirc), > But this is trivially easy to workaround - as in one line of python to > get access to the real modules/functions. > > The only way I could see this working would be to do this on a libc > level - replacing pythons own calls to open() / fopen() etc. But this > also gives high risk of breaking Python its self. > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
