[Python-Dev] Capabilities (we already got one) (original) (raw)

Ben Laurie ben@algroup.co.uk
Wed, 02 Apr 2003 17:22:09 +0100

This message came unglued from the rest of the thread, so I'm going to unglue my response from my catching up with the rest of the thread (which I am partway through at the moment) ;-)

Phillip J. Eby wrote:

>However, you don't use the same technique to control access to Python modules >such as the zipfile module, because the "import zipfile" statement will give the >current scope access to the zipfile module even if nobody has granted such >access to the current scope. >... >So your solution to this, to prevent code from grabbing privileges willy nilly >via "import" and builtins, is rexec, which creates a scope in which code >executes (now called a "workspace"), and allows you to control which builtins >and modules are available for code executing in that "workspace".

Almost. I think you may be confusing module code and module objects. Guido pointed this out earlier. A Python module object is populated by executing a body of code against the module object dictionary. The module object dictionary contains a 'builtins' entry that gives it its "base" capabilities. Module objects possess capabilities, which are in their dictionary or reachable from it. Code doesn't possess capabilities except to constants used in the code. So access to code only grants you capabilities to the code and its constants. So, in order to provide a capability-safe environment, you need only provide a custom import which uses a different 'sys.modules' that is specific to that environment. At that point, a "workspace" consists of an object graph rooted in the supplied 'builtins', locals(), globals(), and initially executing code. We can then see that the standard Python environment is in fact a capability system, wherein everything is reachable from everything else.

I'm not quite sure what you mean by this. Of course, the fact that Python doesn't seem to be all that far from a capability system is one of the attractions, but until the holes you mention (and perhaps others) are plugged, it isn't a capability system.

The "holes" in this capability system, then, are: 1. introspective abilities that allow "breaking out" of the workspace (such as the ability to 'sys.getframe()' or examine tracebacks to "reach up" to higher-level stack frames) 2. the structuring of the library in ways that equate creating an instance of a class with an "unsafe" capability. (E.g., creating instances of 'file()') coupled with instance->class introspection 3. Lack of true "privacy" for objects. (Proxies are a useful way to address this issue, because they allow more than one "capability" to exist for the same object.)

Of course, once you have a capability system, you get the effect of more than one capability for the same object for free, as it were, simply by, err, proxying with other objects.

The objection to doing it the other way round is that for capability languages to be truly usable the capability functionality needs to be automatic, not something that is painfully added to each class or object (at least, that is the claim we capability mavens are making).

Cheers,

Ben.

-- http://www.apache-ssl.org/ben.html http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff