<br>>Yes, that would be one way to do it. Perhaps a render appliance. Well this has some disadvantages, first, larger memory consumption, second,<br> this is possible if you set up your own renderfarm. If you set up your own renderfarm, then you don't<br>need to worry about security from your own files. <br>This was about projects like Sheep-it, Burp, renderfarm.fi, and then about all sorts of commercial renderfarms around the world, <br>which mostly also offer blender rendering, but probably all with default blender settings.<br><br>But this all seems to me like restarting the discussion, which allready came to some conclusions.<br><br>
On Thu, Jun 5, 2014 at 12:29 AM, Daniel Salazar - patazstudio.com < <a href='http://lists.blender.org/mailman/listinfo/bf-committers'>zanqdo at gmail.com</a>> wrote: ><i> That sounds like a VM to me? </i>><i> Daniel Salazar </i>><i> patazstudio.com </i>><i> </i>><i> </i>><i> On Thu, Jun 5, 2014 at 1:07 AM, Dahlia Trimble <<a href='http://lists.blender.org/mailman/listinfo/bf-committers'>dahliatrimble at gmail.com</a>> </i>><i> wrote: </i>><i> > Rather than trying to sandbox python or limit functionality, why not just </i>><i> > sandbox the environment blender is running in? One could set up a render </i>><i> > server which clones a previously set up user with all the necessary </i>><i> > software installed in the user's path and setroot it so it can't touch </i>><i> > anything outside of it's home directory. Any render scripts could do </i>><i> > whatever they want and when finished, the user could be archived or </i>><i> > deleted. No need to worry about any malicious scripts because if they </i>><i> mess </i>><i> > anything up it would only be in the temporary user's space and it would </i>><i> be </i>><i> > deleted once the job is finished. </i>><i> > </i>><i> > </i>><i> > On Wed, Jun 4, 2014 at 11:17 PM, Daniel Salazar - patazstudio.com < </i>><i> > <a href='http://lists.blender.org/mailman/listinfo/bf-committers'>zanqdo at gmail.com</a>> wrote: </i>><i> > </i>><i> >> In my experience non techy people will happily ignore the little </i>><i> >> warning we have (happens over and over to my clients and coworkers). I </i>><i> >> propose making a blocking popup like this: </i>><i> >> </i>><i> >> This file contains drivers and python scripts that have been disabled </i>><i> >> for security reasons. </i>><i> >> </i>><i> >> * Continue with disabled drivers and scripts </i>><i> >> * Reload with enabled drivers and scripts (trusted sources only) </i>><i> >> * Always open files with enabled drivers and scripts (trusted sources </i>><i> only) </i>><i> >> </i>><i> >> This will make it easier for people to understand what's happening and </i>><i> >> ensure it can't be ignored. </i>><i> >> </i>><i> >> Daniel Salazar </i>><i> >> patazstudio.com </i>><i> >> _______________________________________________ </i>><i> >> Bf-committers mailing list </i>><i> >> <a href='http://lists.blender.org/mailman/listinfo/bf-committers'>Bf-committers at blender.org</a> </i>><i> >> <a href='http://lists.blender.org/mailman/listinfo/bf-committers'>http://lists.blender.org/mailman/listinfo/bf-committers</a> </i>><i> >> </i>><i> > _______________________________________________ </i>><i> > Bf-committers mailing list </i>><i> > <a href='http://lists.blender.org/mailman/listinfo/bf-committers'>Bf-committers at blender.org</a> </i>><i> > <a href='http://lists.blender.org/mailman/listinfo/bf-committers'>http://lists.blender.org/mailman/listinfo/bf-committers</a> </i>><i> _______________________________________________ </i>><i> Bf-committers mailing list</i> _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers