[Python-Dev] Capabilities (original) (raw)

Ka-Ping Yee ping@zesty.ca
Mon, 10 Mar 2003 04:51:40 -0600 (CST)

Ben Laurie wrote:

BTW, if you would like to explain why you don't think bound methods are the way to go on python-dev, I'd love to hear it.

Guido van Rossum wrote:

Using capabilities, I would have to hand her a bunch of capabilities for various methods: getitem, haskey, get, keys, items, values, and many more. Using proxies I can simply give her a read-only proxy for the object. So proxies are more powerful.

There seems to be a persistent confusion here that i would like to dispel: a capability is not a single lambda.

Guido's paragraph, above, seems to believe that it is. In fact, the pattern he described is a common and powerful way of using capabilities. A capability is just an unforgeable object reference. In a pure capability system, the only thing you can do with a capability is to call methods on it (or, if you prefer, all you can do is send messages to it). Interposing an object to expose only a subset of another object's API, such as a read-only subset, is exactly the power capabilities give you.

It seems to me that the "rexec vs. proxy" debate is really about a very different question: How do we get from Python's currently promiscuous objects to properly restricted objects?

(Once we have properly restricted objects in either fashion, yes, definitely, using proxies to restrict access is a great technique.)

If i understand correctly, the "proxy" answer is "we create a special wrapper object, then the programmer has to individually wrap any object they want to be secure". And the "rexec" answer is "we create an interpreter mode in which all objects are secure".

I think the latter is far better. To have any sort of real chance at establishing security, you have to start from a place where everything is secure, instead of starting from a place where everything is insecure and you have to individually secure every single object with its own wrapper.

The eventual ideal is to have a system where all objects are "pure" objects (i.e. non-introspectable capabilities) by default. Anyone wanting to do introspection would simply have to obtain the "introspect" capability from a privileged place (e.g. sys). For example,

class Foo:
    pass

print Foo.__dict__                  # fails

from sys import introspect
print introspect(Foo).__dict__      # succeeds

When running the interpreter in secure mode, "introspect" would just be missing from the sys module (again, ideally sys.introspect wouldn't exist by default, and a command-line option would turn it on, but i realize that's far away).

This would have the effect of the "introspectable flag" that Guido mentioned, but without expending any storage at all, until you actually needed to introspect something.

-- ?!ng