From: "Ben Laurie" <ben@algroup.co.uk>
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?
there is a difference: proxies cover indipendently much of the holes in restricted execution ... about restricted execution: - the way a new frame acquires the default built-ins vs. installed resticted bult-ins is likely correct but needs auditing; e.g. the last problem fixed related to this was: http://python.org/sf/577530 - under restricted execution some operation, in particular reflective ops ought to be prohibited, the code that implements this is scattered and/because this operations share the same execution paths with "normal" ops; so the first thing is enumerate all that should be prohibited, or devise an approach to security that can work with just a minimal set of guarantees (disabled ops and/or encapsulated objects) These were e.g. identified "problems": http://mail.python.org/pipermail/python-dev/2002-December/031160.html http://mail.python.org/pipermail/python-dev/2003-January/031851.html