Re: [Python-Dev] Capabilities (we already got one)

(I, Zooko, wrote the lines prepended with "> > ".) Guido wrote:
Yes. That may be why the demand for capabilities has been met with resistance: to quote the French in "Monty Python and the Holy Grail", "we already got one!" :-)
;-) Such skepticism is of course perfectly appropriate for proposed changes to your beautiful language. More on the one you already got below. (I agree: you already got one.)
Here's a two sentence definition of capabilities:
I've heard too many of these. They are all too abstract.
There may have been a terminological problem. The word "capabilities" has been used for three different systems -- "capabilities-as-rows-of-the-Lampson-access- control-matrix", "capabilities-as-keys", and "capabilities-as-references". Unfortunately, the distinction is rarely made explicit, so people often assert things about "capabilities" which are untrue of capabilities-as-references. (Ping has just written a paper about this.) The former two kinds of capabilities have major problems and are disliked by almost everybody. The last one is the one that Ping, Ben Laurie and I are advocating, and the one that you already got. Anyway, if someone gave a definition of capabilities-as-references and it didn't match with the two-sentence definition I gave (and with the diagram), then it was wrong. Here's the two-sentence definition again:
Authority originates in C code (in the interpreter or C extension modules), and is passed from thing to thing.
This part I like.
A given thing "X" -- an instance of ZipFile, for example -- has the authority to use a given authority -- to invoke the real open(), for example -- if and only if some thing "Y" previously held both the "open()" authority and the "authority to extend authorities to X" authority, and chose to extend the "open()" authority to X.
But the instance of ZipFile is not really a protection domain. Methods on the instance may have different authority.
Okay, ZipFile was the wrong example. Here it is without examples: Abstract version: A given thing "X" can use a given authority "S" if and only if some thing "Y" has previously held both the authority and the "authority to extend authorities to X" and chose to extend "S" to X. To make it concrete, I will use the word "object" to mean "anything referenced by a Python reference". This includes class instances, closures, bound methods, stack frames, etc. When I mean Python's instance-of-a-class "object", I'll say "instance" instead of "object". So the concrete version is: Concrete version: An object "X" can use an object "S" if and only if some object "Y" has previously held references to both S and X, and chose to give a reference to S to X. (Quoting out of order:)
Hm. Reviewing the rexec docs, I being to suspect that the "access control system with unified designation and authority" *is* how Python does access control in restricted mode, and that rexec itself is just to manage module import and certain dangerous builtins.
Yes. [...] Sure. The question is, what exactly are Alice, Bob and Carol? I claim that they are not specific class instances but they are each a "workspace" as I tried to explain before. A workspace is more or less the contents of a particular "sys.modules" dictionary.
I believe I understand the motivation for rexec now. I think that in restricted-execution-mode (hereafter: "REM", as per Greg Ewing's suggestion [1]), Python objects have encapsulation -- one can't access their private data without their permission. Once this is done, Python references are capabilities. So if you have a Python object such as a wxWindow instance, and you want to control access to it, the natural way to do that is to control how references to it are passed around. This is why you've already got one. The natural and Pythonic way to control access to Python objects is with capabilities, and that's what you've been doing all along. However, you don't use the same technique to control access to Python *modules* such as the zipfile module, because the "import zipfile" statement will give the current scope access to the zipfile module even if nobody has granted such access to the current scope. This is a violation of the two-sentence definition and of the graph: the current scope just gained authority ex nihilo. So your solution to this, to prevent code from grabbing privileges willy nilly via "import" and builtins, is rexec, which creates a scope in which code executes (now called a "workspace"), and allows you to control which builtins and modules are available for code executing in that "workspace". Now access to modules conforms to the definition of capabilities: an object X can access a module S if and only if some object Y previously had access to X's workspace and to S, and Y chose to give X access to S. So unless I've missed something, rexec conforms to the definition of capabilities as well. (Of course, one can always build other access-control mechanisms on top of capabilities. In particular, the rexec "hooks" mechanism seems intended for that.) Regards, Zooko http://zooko.com/ ^-- under re-construction: some new stuff, some broken links [1] http://mail.python.org/pipermail/python-dev/2003-March/034311.html

On Tue, 2003-04-01 at 11:47, Zooko wrote:
I think that in restricted-execution-mode (hereafter: "REM", as per Greg Ewing's suggestion [1]), Python objects have encapsulation -- one can't access their private data without their permission.
Once this is done, Python references are capabilities.
REM does not provide object encapsulation, but it disables enough introspection that it is possible to provide encapsulation. The REM implementation provides a Bastion function that creates private state by storing the state in func_defaults, which is inaccessible in REM. Jeremy

On Tue, 1 Apr 2003, Zooko wrote:
I think that in restricted-execution-mode (hereafter: "REM", as per Greg Ewing's suggestion [1]), Python objects have encapsulation -- one can't access their private data without their permission.
Once this is done, Python references are capabilities.
Aaack! I wish you would *stop* saying that! There is no criterion by which a reference is or is not a capability. To talk in such terms only confuses the issue. It is possible to program in a capability style in any Turing-complete programming language, just as it is possible to program in an object style or a functional style or a procedural style. The question is: what does programming in a capability style look like, and how might Python facilitate (or even encourage) that style? To say that activating restricted execution mode causes things to "become" capabilities is as meaningless as saying that adding a feature to the C language would suddenly turn an arbitrary C program into an object-oriented program. -- ?!ng

On Tue, 1 Apr 2003, Ka-Ping Yee wrote:
On Tue, 1 Apr 2003, Zooko wrote:
I think that in restricted-execution-mode (hereafter: "REM", as per Greg Ewing's suggestion [1]), Python objects have encapsulation -- one can't access their private data without their permission.
Once this is done, Python references are capabilities.
Aaack! I wish you would *stop* saying that!
There is no criterion by which a reference is or is not a capability. To talk in such terms only confuses the issue.
I take the above, with a bit of license, to mean that REM enables encapsulation for python objects, so they are closer to being safe to use as capabilities. Subsequent posts suggest that encapsulation isn't actually achieved, but that's not the issue here - the issue, as i understand it, is how to talk about enabling capability-based safety in python code.
It is possible to program in a capability style in any Turing-complete programming language, just as it is possible to program in an object style or a functional style or a procedural style. The question is: what does programming in a capability style look like, and how might Python facilitate (or even encourage) that style?
I think the last part is, more specifically, "what measures need to be taken to enable safe use of python objects for capability style programming?"
To say that activating restricted execution mode causes things to "become" capabilities is as meaningless as saying that adding a feature to the C language would suddenly turn an arbitrary C program into an object-oriented program.
I'm not near as clear about all this as you seem to be, but i have the feeling the statements are not as meaningless as you're suggesting. I *do* think that getting more clear about what the questions are that we're trying to answer would be helpful, here. One big one seems to be: "What needs to be done to enable effective ("safe"?) use of python object (references) as capabilities?" I've seen answers to this roll by several times - i think we need to settle them, and collect the conclusions in a PEP. And we need to identify what other questions there are. One more probably is, "how do we use python objects as capabilities, once we can ensure their safety?" And maybe it'd be helpful to elaborate what "safety" means. -- Ken klm@zope.com Alan Turing thought about criteria to settle the question of whether machines can think, a question of which we now know that it is about as relevant as the question of whether submarines can swim. -- Edgser Dijkstra

Ken Manheimer wrote:
On Tue, 1 Apr 2003, Ka-Ping Yee wrote: One big one seems to be: "What needs to be done to enable effective ("safe"?) use of python object (references) as capabilities?" I've seen answers to this roll by several times - i think we need to settle them, and collect the conclusions in a PEP. And we need to identify what other questions there are.
I am in the process of writing a PEP, and it is being informed by this discussion. Unfortunately, I have several day jobs and its going somewhat slowly. I've also been bogged down somewhat in a theoretical discussion with a bunch of capability experts over globals and how they should work. However, we do appear to have reached closure on that issue: globals have to be at least transitively immutable - unfortunately, I have demonstrated that this requirement is not sufficient to make them safe, but it is (we believe) necessary. So, now I've sorted that one out I can complete my first pass on the PEP, which I expect to do in the next few days. At that point, I'm slightly unsure how best to proceed. The most obvious way is, of course, to follow the standard PEP procedure, but are there people who would like to comment before I submit the first draft? It is still going to be full of unanswered questions, but I do think we are near to the stage where we can start nailing down the answers. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
participants (5)
-
Ben Laurie
-
Jeremy Hylton
-
Ka-Ping Yee
-
Ken Manheimer
-
Zooko