[Bf-committers] Patch: removing use of exec() and eval() from python source

[Campbell Barton]

Blender has a C function to get rna paths which I intended to use if
exec/eval are a problem.
another reason I did not write this is that it should support index
lookups, not just attributes since "blah[1].foo[13]" is a valid rna
sting, from what I gather your function does not support index lookups
and assignments.

as for security, if you can change someones configuration to inject
python code - you would already be able to modify their config in ways
that do other bad things.
for instance - keybindings are saved as a python script, so if you
share keybindings, injecting code into an operator is no worse then
what you could do in the python script to begin with.

On Tue, Oct 20, 2009 at 10:09 PM, Mathias Panzenböck
<grosser.meister.morti at gmx.net> wrote:
> I've written a patch that removes the usages of eval() and exec() from the files:
> release/scripts/modules/bpy_ops.py
> release/scripts/ui/space_userpref.py
>
> These functions are used to get and set property paths like:
> exec("context.%s='%s'" % (self.path, self.value)) # security nuts will complain.
> orig_value = eval("context.%s" % self.path) # security nuts will complain.
>
> The comments already indicate that this is not how one should write this. I
> think this is nut just a security issue, it is also hard to read and plain ugly.
>
> I wrote two tiny python functions you can use instead:
> setpath(context, self.path, self.value)
> orig_value = getpath(context, self.path)
>
> My version is cleaner, shorter, easier to read, gives the right (or at leas a
> better) exception when something is wrong[1], works with all values (why "'%s'"
> was used in the above code and not "%r"?) and does not allow script injections.
> It might even be faster (I don't know, didn't test this), because nothing has to
> be compiled. Also I reduced code duplication a tiny bit.
>
> The getpath and setpath functions should probably be placed in some kind of
> utility module.
>
> [1] Well, the first of the two patches attached to the bug entry does not
> complain about setting an illegal name because pythons setattr() eats it without
> complaint, so where "context.%s=%s" would raise a syntax error the first version
> would pass.
>
> The second patch checks the name before it sets it, but it is more strict than
> python: It does not allow leading underscores and no non-alphanumeric-unicode
> characters (there are such characters allowed by python 3).
>
> See:
> https://projects.blender.org/tracker/index.php?func=detail&aid=19695&group_id=9&atid=127
>
> Regards,
> Mathias Panzenböck (panzi)
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell