Creating a capabilities-based restricted execution system

[Sean R. Lynch]

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.