From: "Guido van Rossum" email@example.com
I think I agree that to really get on top of this security business we need to move towards having dangerous things forbidden by default rather than allowed by default.
This is more or less what the rexec module implements, except for convenience it has a list of unsafe built-ins rather than a list of safe built-in.
To that end, it would be useful if we could pin down exactly what's dangerous and what isn't. It seems to me that most uses of introspection by most programs are harmless. Can we sort out those (hopefully few) things that are dangerous, and separate them from the existing introspection mechanisms?
Maybe, maybe not. The original restricted execution code (not the rexec module) arbitrarily decided that setting class attributes was dangerous but getting them was not. Samuele found that new-style classes allow both, but always disallows write-access to the class __dict__ (you have to use the setattr protocol); this is good or bad depending on how it's used.
but given that methods can be overriden per instance with classic-classes:
class C: def f(s): ...
c=C() c.f = lambda s: s
it was not so effective.
The real problem is that harmful access may be granted via innocent-looking access. For example, allowing read-only access to a function's globals gives you access to the unrestricted 'open' function...
restricted execution alone for example does not have a notion of subclassable vs. non subclassable classes, and given its approach, subclassing can be dangerous.
For sure a good thing would be for func_* and im_* attributes of functions and methods to be substituted by special accessor functions/objects, indipendently of restricted mode.
Function and method should be for normal code basically opaque.