[Python-Dev] Capabilities

[Guido van Rossum]

[Someone else]
> >>Maybe every Python object should have a flag which
> >>can be set to prevent introspection -- like the current
> >>restricted execution mechanism, but on a per-object
> >>basis. Then any object could be used as a capability.

> Guido van Rossum wrote:
> > I think the capability folks would object to calling it a capability
> > though. :-)

[Ben]
> No, objects are another way to do it, though it seems to me with 
> somewhat less ease - because the most common use of capabilities is to 
> restrict the type of access to objects other objects have, so you'd need 
> to have multiple objects proxying to the "real" one if you do it at the 
> object level.

I'm not sure I understand.  Do you mean that because there may be
several security levels you'd need different capabilities for an
object for each level?  Since there are also several methods, you
end up managing multiple capabilities in either case.

Anyway, Zope security proxies aren't "managed" this way.  The trusted
code doesn't have a set of objects representing capabilities that it
hands out -- a proxy is manufactured freshly on each use.  I wonder if
this might be one cause of repeated misunderstandings?

> If we were going to go this route, I'd like the alternative of _also_ 
> being able to set the flag on a bound method.
> 
> > Two questions:
> > 
> > - Where to store the flag?  It probably would cost 4 bytes per object.
> 
> You can swap space for time by storing it as an attribute, of course.

Not all Python objects have a dict where to store arbitrary
attributes.  And even if they do, that's about the most expensive way
to store a flag.  And you'd have to worry about someone getting a hold
of that dict and deleting the attribute (assuming that the flag
defaults to allow introspection, otherwise no Python code written
today would continue to work).

> > - Which attributes are considered introspective?
> 
> All of them, except methods.

That's not very Pythonic.

> Of course, this is what my first approximation to capabilities did 
> (that's what a "capclass" was).

I never knew what a capclass was.  I don't think you ever explained
it so clearly ("doesn't allow access to non-method attributes")
before.

--Guido van Rossum (home page: http://www.python.org/~guido/)