[Python-Dev] new security doc using object-capabilities (original) (raw)

Phillip J. Eby pje at telecommunity.com
Mon Jul 24 08:10:44 CEST 2006

At 09:27 PM 7/23/2006 -0700, Brett Cannon wrote:

On 7/23/06, Phillip J. Eby <<mailto:pje at telecommunity.com>pje at telecommunity.com> wrote:

one proxy plus one namechecker equals one capability. In other words, you could take the restricted interpreter, the proxy mechanism, and the namechecker and leave most of the rest alone, and you'd have your capability system. Then you could focus more time and attention on the parts of the problem that Zope doesn't solve, instead of reinventing the ones that it already does. Right, but I am trying to remove the need for a namechecker which makes it an object-capabilities system.

As I said above: a namechecker plus a proxy equals an object capability.

When I say "name checker" I mean the Zope type that allows you to specify a list of names that are allowed for a given object. This allowing is not based on identity or code signing or anything like that. It's just a list of attribute names: i.e. a capability mask over an existing object.

When you create a proxy using this name mask, that proxy becomes a capability that allows access to the given names on the underlying object.

I like the fundemental design difference of object-capabilities

It's not a difference at all, let alone a fundamental one. Zope just happens to allow other kinds of security checking in addition to capabilities, if you want them. However, most of its more basic encapsulation features are 100% capability based.

Meanwhile, if you want to implement an object-capability system, you will need something that is basically a mask, to allow one piece of code to create capabilities that can be given to another. What you end up with for doing that is going to look almost exactly like a Zope proxy plus a Zope name checker.

I hate to harp on this point, but there seems to be a trend that when people have capabilities on their mind, they tend to look at Zope and dismiss it as not being capability-based, when in fact Zope's approach is capabilities plus other things.

(Of course, most of those "other things" have to do with closing holes like subclasses, while improving performance by still allowing lots of common objects not to be proxied.)

More information about the Python-Dev mailing list