Brecht Van Lommel wrote: > First is that there is a difference between python scripts, one > category is scripts to extend blender like exporters. These > fundamentally can't run inside a sandbox since they need to access > files. >
This is, indeed, not new and I know it has been mentioned multiple times in this "thread" given I've mentioned it more than once :) The fact of the matter is exporters/importers need to access the file system to work. That is basically the definition of their existence - moving data between Blender's internal state to the file system & back. > To sum up my opinion, sandboxing is very hard and not something we can > solve once, it requires continuous attention, so let's not even try > it. Instead, the install addon operator should warn about security > problems, and loading a .blend file with scripts should become easier > for users. > Actually, sand-boxing scripts is quite easy provided you use a platform that supports it. Python currently does not support this so the task seems insurmountable; but only so long as you look through the Python lens. It is quite simple to sandbox applications using Lua - simply don't give them access to the unsecure functionality. If you don't want the user reading/writing files not explicitly handed to them? Then don't give them access to the "io" library (by excluding it from the VM's initialisation). Don't want to give the person access to the operating system, don't add the "os" module to those accessible by the VM. And so on. Python has an unofficial design foundation that developers should "extend Python" with their application rather than "embed Python" into their application. As such, Python exposes everything one would need in an application platform - file access, network sockets, operating system calls, etc. Unlike Java (another extend vs embed platform), this was all done on the assumption that you wouldn't WANT to limit the virtual machine running Python from accessing these resources. Other parts of the system get written on the (valid) assumption the unsecure functionality will be exposed and so removing file/socket access & the like becomes an exercise in "hunt the bug" throughout the entire Python platform/standard library. Other languages / virtual machines are designed with an "embedding" mentality. You need to explicitly expose the functionality you want to use in a script to the virtual machine. Most of the good ones come with standard libraries to access these features but they can be disabled with the commenting of a handful of lines at most. In addition, the best embedded virtual machines give you explicit hooks (or outline the internal code to change) enabling the end user to override the memory allocation & CPU usage (i.e. byte-code instructions run without break). Also, the Firefox analogy is a good one to use. There are two levels of scripts Firefox runs - the "plugin scripts" which can access your hard-drive, use Firefox services to retrieve data online, etc and then there are "content scripts" - the JavaScript that gets run in your browser when you navigate to a site using it. Unless some explicit exception is in place - the JavaScript from the web-pages cannot access the content of your hard drive because it was never given access to the classes/functions that allow this. However the plugin scripts DO have the capability of accessing these services because the JavaScript VM adds classes/functions to allow this. The browser downloaded scripts are "sand-boxed" like we would desire our scripted constraints & rig drivers to be whereas the Firefox add-ons are given more functionality like we desire our import/export scripts to be. Where bugs in this show up, it is generally not so much to do with the sand-boxing as memory overruns & the like that are a separate problem Blender would have to deal with anyway. In summary, sand-boxing is not hard provided you use the right platform nor does it need "continuous attention". You set up the trusted & untrusted virtual machines with the functionality they are allowed to have and that is all. Adding "exceptions" is easy enough, flag the scripted constraint / driver as requiring access to the file system, add the file system functionality to the scene VM and raise a warning when opening it. -- Regards, Benjamin Tolputt Analyst Programmer _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers