[Python-Dev] Capabilities (original) (raw)

Guido van Rossum guido@python.org
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.

[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/)