[Python-Dev] Re: Capabilities

[Ben Laurie]

Guido van Rossum wrote:
> [Moving a discussion about capabilities to where it arguably belongs]
> 
> [Ben Laurie]
> 
>>The point about capabilities is that mere possession of a capability is 
>>all that is required to exercise it. If you start adding security 
>>checkers to them, then you don't have capabilities anymore. But the 
>>point is somewhat deeper that than - given capabilities, you can 
>>implement proxies without requiring any more infrastructure - you can 
>>also implement security schemes that don't really correspond to any kind 
>>of security checking at all (ok, you can probably find some convoluted 
>>way to achieve the same effect, but I'll bet it comes down to having 
>>tokens that correspond to proxies, and security checkers that allow you 
>>to proceed if you have the appropriate token - in other words, 
>>capabilities, but very hard to use).
>>
>>So, it seems to me, its simpler and more powerful to start with 
>>capabilities and build proxies on top of them (or whatever alternate 
>>scheme you want to build).
>>
>>Once more, my apologies for not just getting straight to the point.
>>
>>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.
> 
> 
> It seems to e a matter of convenience.  Often objects have many
> methods to which you want to provide access as a group.  E.g. I might
> have a service configuration registry object.  The object behaves
> roughly like a dictionary.  A certain user may be given read-only
> access to the registry.  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.
> 
> Before you start saying that we should use capabilities as the more
> fundamental mechanism and build proxies on top of that: as you point
> out, we already have an equivalent more fundamental mechanism, bound
> methods, which is equivalent to capabilities.  It's just that raw
> capabilities aren't very usable, so one way or another we've got to
> build something on top of that.

I'm not trying to persuade you that capabilities are better than 
proxies. I'd prefer to build on them, and it seems you'd prefer to do it 
another way. That's fine with me - my goal is to make capabilities both 
possible and easily usable in Python, not to persuade everyone to use 
them (yet ;-).

Bound methods are not capabilities unless they are secured. It seems the 
correct way to do this is to use restricted execution, and perhaps some 
other tricks. What I am trying to nail down is exactly what needs doing 
to get us from where we are now to where capabilities actually work. As 
I understand it, what is needed is:

a) Fix restricted execution, which is in a state of disrepair

b) Override import, open (and other stuff? what?)

c) Wrap or replace some of the existing libraries, certify that others 
are "safe"

It looks to me like a and b are shared with proxies, and c would be 
different, by definition. Is there anything else? Am I on the wrong track?

I am going to write this all up into a document which can be used as a 
starting point for work to complete this.

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