[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