[Python-3000] Reminder: Py3k PEPs due by April (original) (raw)

Phillip J. Eby pje at telecommunity.com
Tue Apr 10 22:47:44 CEST 2007

At 12:25 PM 4/10/2007 -0700, Brett Cannon wrote:

On 4/10/07, Phillip J. Eby <<mailto:pje at telecommunity.com>pje at telecommunity.com> wrote:

At 12:03 PM 4/10/2007 -0700, Brett Cannon wrote: >2. Remove file.init, code.init, and object.subclasses for >security reasons.

The subclasses method is useful -- even more so in 3.x than in 2.x, because in 3.x there are no classic classes. I was planning to make use of this in my generic function libraries to allow automatic checking for completeness and ambiguity of a ruleset, given the classes that are currently defined. Currently, this is limited by the inability to access classic classes' subclasses, but in 3.x subclasses is an ideal way to locate active classes. The problem with it, though, is it does expose so much.

From my POV, that's a feature, not a bug. :)

If I have a class defined that is not exposed within the interpreter but is live in the process, I can still get to it with this method. That's a problem if the class has a security component to it where there is a class attribute that should not be exposed within the interpreter.

This can be discussed more if/when I get my security paper out in the public and get a PEP written to actually push for the removals.

If you're using a capabilities-based system (or a multiparadigm system like Zope 3's zope.security), it's easy enough to restrict access to special attributes like subclasses (or for that matter, any other sensitive attributes), so I don't see why the feature itself needs to be removed.

More information about the Python-3000 mailing list