Tue, 11 Mar 2003 18:02:36 +0100
From: "Guido van Rossum" <email@example.com>
> [Greg Ewing]
> > 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:
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'
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.