[Python-Dev] new security doc using object-capabilities

[Phillip J. Eby]

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.)