[Python-Dev] Capabilities

[Paul Prescod]

Guido van Rossum wrote:
>...
> 
>>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.

Given that Zipfile("/tmp/foo.zip") can read a zipfile, the zipfile class 
clearly has the ability to open files. It derives this ability from the 
fact that it can get at open(), os.open etc. In a capabilities world, it 
should not have access to that stuff unless the caller specifically gave 
it access. And the logical way for the caller to give it that access is 
like this:

ZipFile(already_opened_file)

But in restricted code

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

I think that's the problem. the ZipFile module has a back-door 
"capability" that is incredibly powerful. In a library designed for 
capabilities, its only access to the outside world would be via data 
passed to it explicitly.

> 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?

In the sense that it can import "open" or "os.open" rather than being 
forced to only communicate with the world through objects provided by 
the caller. If we imagine a world where it has no access to those 
back-doors then I can't see why Ping's complaint about access to classes 
would be a problem.

  Paul Prescod