[Python-Dev] Re: Capabilities in Python

Ben Laurie ben@algroup.co.uk
Sat, 01 Feb 2003 12:06:46 +0000


Ka-Ping Yee wrote:
> Wow, how did this topic end up crossing over to this list while
> i wasn't looking?  :0
> 
> Ben Laurie wrote:
> 
>>I'll admit to being that person. A capability is, in essence, an
>>opaque bound method. Of course, for them to be much use, you
>>want the system to provide some other stuff, like not being able
>>to recreate capabilities (i.e. you get hold of them from on
>>high, and that's the _only_ way to get them).
> 
> 
> Jeremy Hylton wrote:
> 
>>That seems like a funny defintion of a capability.
> 
> 
> A better definition of "capabilitiy" is "object reference".
> 
> "Bound method" isn't enough, because a capability should be able
> to have state, and your system should have the flexibility to
> represent capabilities that share state with other capabilities,
> or ones that don't.  The simple, straightforward way to model this
> is to just equate the word "capability" with "object reference".

You can it that way, too, but it strikes me as more unwieldy in 
practice. A bound method also has state because it is, of course, bound 
to an object reference, so I find that a more elegant way to do it.

>>A capability system must have some rules for creating and copying
>>capabilities, but there is more than one way to realize those rules in
>>a programming language.
> 
> 
> I suppose there could be, but there is really only one obvious way:
> creating a capability is equivalent to creating an object --
> which you can only do if you hold the constructor.  A capability
> is copied into another object (for the security folks, "object"
> == "protection domain") when it is transmitted as an argument to a
> method call.
> 
> To build a capability system, all you need to do is to constrain
> the transfer of object references such that they can only be
> transmitted along other object references.  That's all.
> 
> The problem for Python, as Jeremy explained, is that there are so
> many other ways of crawling into objects and pulling out bits of
> their internals.
> 
> Off the top of my head, i only see two things that would have to
> be fixed to turn Python into a capability-secure system:
> 
>   1. Access to each object is limited to its declared exposed
>      interface; no introspection allowed.
> 
>   2. No global namespace of modules (sys.modules etc.).
> 
> If there is willingness to consider a "secure mode" for Python
> in which these two things are enforced, i would be interested
> in making it happen.

I believe you just described rexec.

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