Guido van Rossum
Sun, 30 Mar 2003 19:09:52 -0500
> > [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.
> > 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?
> 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
> 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/)