At 12:25 PM 4/10/2007 -0700, Brett Cannon wrote: >On 4/10/07, Phillip J. Eby ><<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> 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. _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
