[Bf-committers] Python status

[Willian Padovani Germano]

----- Original Message -----
From: "Charles Wardlaw" <kattkieru@yahoo.com>
To: <bf-committers@blender.org>
Sent: Saturday, May 17, 2003 4:30 PM
Subject: Re: [Bf-committers] Python status


> If the script is distributed with Blender, as with the Yafray script,
> wouldn't the script menu function be a nice side-addition?  Perhaps the
> default b.blend would include yafray export / import and VRML
> import/export in that menu by default.  The scripts could live in the
> ~/.blender/plugins directory, or in the app bundle on OSX.

Yes, after exppython substitutes the current implementation, integrating
python scripts into Blender menus, etc. will be a natural step.  Users
shouldn't need to care whether some Blender functionality was written in C,
C++ or python.

It will also be nice to have some python scripts bundled with Blender
itself, like importers / exporters for many 3d formats, etc.  That'll also
make them safer, which brings us to:

> > Security issues:
> First, a disabling of potentially dangerous functions by way of a global
> program variable / toggle button in the userprefs.  Or maybe a security
> section, that (dis)allows the running of python scripts at blender
> startup, or the running of dangerous functions, or allows the user to
> run with gleeful abandon into the arms of whatever evil script-kiddies
> can come up with.  User choice.

Sure, that's the thought, one way or another.  But we need to investigate
how to do this.  We have scripts (that may come in .blend files or alone, in
source form or compiled) and we pass them to the Python Interpreter.

Guignot proposed the Python module rexec -- Restricted execution framework.
>From the Python docs, Global Module Index:

"This module contains the RExec class, which supports r_eval(),
r_execfile(), r_exec(), and r_import() methods, which are restricted
versions of the standard Python functions eval(), execfile() and the exec
and import statements. Code executed in this restricted environment will
only have access to modules and functions that are deemed safe; you can
subclass RExec to add or remove capabilities as desired.

Note: The RExec class can prevent code from performing unsafe operations
like reading or writing disk files, or using TCP/IP sockets. However, it
does not protect against code using extremely large amounts of memory or
processor time. "

So, it looks like a nice solution for the worst part of the problem.  And if
it works (guignot brought it up and proposed to investigate), we can then
make it a user choice to execute a script in "safe mode" or not.

> Second, a check to see whether blender's being run as a super user --
> then a second set of failsafe's could come into play, disallowing
> dangerous function usage, period, unless blender's run with a special
> command line, or something.

Yes, that's another way of applying the same kind of protection.  I don't
know how many of the systems Blender runs in have a "super user" concept,
though, but any without it could be put in safe mode by default, of course.

> Third: some kind of script signing?  I know there was talk of removing
> OpenSSL, so this might not be the best of ideas, and signatures can be
> faked, leading us back to options one and two.

Yes, this one would add complexity and maybe not help enough.

I like the idea of some scripts that don't evolve too fast (like good,
stable importers / exporters, again) coming with Blender itself, in source
form (.py, not compiled), with the same licence as Blender's, of course.

And also an online repository, probably at blender.org, with a catalog of
scripts by cathegory, with version numbers, link to author's page (but the
script itself should be available from the main repository site, no 404's
mess), scores, etc.   This structure is a fast way of catching any problem
with scripts.

Then, as you mentioned, users should be warned to be careful about scripts
from other sources, *specially* compiled ones.

Another case, blocking the automatic execution of scripts from .blend files
without the user's explicit permission, is easy.

--
Willian, wgermano@ig.com.br