[Python-Dev] Capabilities

[Ka-Ping Yee]

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__, has_key,
> 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