[Python-Dev] Capabilities

[Guido van Rossum]

> > [Ping]
> > > Having access to a particular instance should certainly not allow
> > > one to ask it for its class, and then instantiate the class with
> > > arbitrary constructor arguments.

[Guido]
> > Assuming the Python code in the class itself is not empowered in any
> > special way, I don't see why not.  So that suggests that you assume
> > classes can be empowered.  I can see this for classes implemented in
> > C; but how can classes implemented in pure Python be empowered?

[Ping]
> In many classes, __init__ exercises authority.  An obvious C type with
> the same problem is the "file" type (being able to ask a file object
> for its type gets you the ability to open any file on the filesystem).
> But many Python classes are in the same position -- they acquire
> authority upon initialization.

What do you mean exactly by "exercise authority"?  Again, I understand
this for C code, but it would seem that all authority ultimately comes
from C code, so I don't understand what authority __init__() can
exercise.

> To pick one at random, consider zipfile.ZipFile.  At first glance it
> appears that once you create a ZipFile object with mode "r" you can
> hand it off to provide read-only access to a zip archive.  (Even if
> a security audit of the code reveals holes, my point is that the API
> isn't far from accommodating such a design intent.)

But is it really ZipFile.__init__ that exercises the authority?  Isn't
its authority derived from that of the open() function that it calls?

> It's useful to be able to separate the authority to read one
> particular instance of ZipFile from the authority to instantiate
> new ZipFiles, which currently allows you to open any zip file on
> the filesystem for reading or writing.

In what sense is the ZipFile class an entity by itself, rather than
just a pile of Python statements that derive any and all authority
from its caller?

I understand how class ZipFile could exercise authority in a
rexec-based world, if the zipfile module was trusted code.  But I
thought that a capability view of the world doesn't distinguish
between trusted and untrusted code.  I guess I need to understand
better what kind of "barriers" the capability way of life *does* use.

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