Creating a capabilities-based restricted execution system
Sean R. Lynch
seanl at chaosring.org
Tue Jan 6 08:04:47 CET 2004
Ok, so how do I handle overriding methods?
Allowing code that inherits from a class to override any method it can
access could result in security problems if the parent doesn't expect a
given method to be overridden. Shadowing the overridden method could
result in unexpected behavior. And, of course, in some cases, we *want*
to allow the programmer to override methods, because this is what code
reuse is all about.
I already have a solution in mind for __init__: provide another method
that is always called on every superclass for any object that is created
from a class that inherits from that superclass. The method takes no
arguments and is called after __init__.
Another option is to simply not provide any protection from inheriting
classes. The more I think about it, the better this sounds. Classes
don't contain any data other than perhaps class data, and a programmer
shouldn't be allowing another programmer to subclass classes that
contain data they want to protect. I could put all attributes back to
being protected (rather than private) by default, and only have a single
extra declaration required in a class statement to declare what
attributes you want to make public.
Can anyone (Serge?) think of an example of a case where this might cause
leaks or privilege escalation? Remember that classes are opaque, so code
can't get at unbound methods. Subclassing a class doesn't give you any
special access to members of that class.
More information about the Python-list