From: "Jonathan S. Shapiro" <>
Replying To: David Wagner <>
Date: 04 Dec 2002 11:14:20 -0500
Subject: Re: [e-lang] "Capability Myths Demolished" (was: Software security workshop)

On Tue, 2002-12-03 at 17:49, David Wagner wrote:
> There are two kinds of mechanisms that might have claim to the name
> capabilities:
>   Lampson-style capabilities: What you call a C-list.
>   E-style capabilities: Things that combine both authorization
>     and designation.
> I suspect you would like to reserve the term "capabilities" for E-style
> capabilities only.  I, however, was taught that the word "capabilities"
> encompasses both styles (or that it refers to Lampson's notion)...

I'm not sure that the disconnect you surmise actually exists.  There *is*
confusion about the term capability created by Netscape, but it is a
different one from the confusion that you have identified.

First, the Lampson defintion *does* combine designation and authority.  A
Lampson capability is an (object-designator, rights) pair in the Lampson
paper. Second, the definition of the term comes from Dennis and van
Horn, who are quite clear that designation is critical. To my knowledge,
there are only three existing "capability" system in which designation
and rights have in fact been separated. The first is the so-called
"split capability" system from Alan Karp and friends, which is a very
nice design in spite of being (IMHO) inaccurately named. Alan may not
agree with me. :-) The second is Netscape capabilities, which even
Netscape concedes were misnamed. The third is POSIX capabilities, which
was a knowing and deliberate choice of naming to undermine the
credibility of the term, made with malice aforethought. alan_karp

A C-list isn't a capability. It is a collection of capabilities.  One of
the key differences in various capability system designs is whether
C-lists are sets or maps. In the "C-list as set" approach, possession of
a capability is required (demonstrated by membership in the C-list), but
operations do not explicitly designate the particular capability they
are using. In some cases they may designate the C-list. This lends
itself to a variety of bugs in code and some interesting ambiguities if
multiple candidate authorities are present in the same C-list: markm markm markm

  1.  Which one should be used, or do we understand this
     to mean the authority that is the union of the presently
     held capabilities? ben

  2.  If union, how is the runtime to understand the correct
     computation of union for user-defined objects (Wulf's
     notion of extensible capability systems in Hydra, or
     start keys in KeyKOS/EROS).

The second model is the "C-list as map" model.  In this model, the
wielder must designate both the C-list and the specific contained
capability under which the operation is to be performed.

Either C-list model falls under the general heading of "capability
systems" in the existing literature.  Because I find extensibility
important and implicit capability designation (note: not object
designation) dangerous, I personally prefer the "C-list as map" model. 


e-lang mailing list