[cap-talk] Wikipedia: Object-capability model - reference vs. capability?
Jed Donnelley
capability at webstart.com
Mon Jan 8 10:52:23 CST 2007
At 02:54 AM 1/8/2007, David Hopwood wrote:
>Jed Donnelley wrote:
>...
> > I still think it would be better to introduce the term
> > "capability" for the reference in the first definition:
> >
> > Objects are both accessed and designated through unforgeable
> > references called "capabilities."
> >
> > Then use 'capability' wherever you have otherwise used
> > "reference." Isn't the term "reference" a more general
> > term? When you say, for example, "objects can embed
> > references in the messages they send" don't you really
> > mean capabilities rather than some other form of reference?
>
>No, because they can embed data, and data is a reference but not
>a capability -- see the glossary section.
Grumble. The above still confuses me. You say data can be a
reference but not a capability, but in the definition aren't we
limiting the discussion to capabilities? In that case shouldn't
we limit the definition to capabilities and not the more general
reference?
To restate more briefly, it seems to me there three reasons that
we should use the term "capability" in place of the term
"reference" after defining a "capability" as a reference to
an object.
1. The "capability" term is more specific as it excludes
potentially other types of confusing references (e.g. data),
and
2. Using the term "capability" makes clear why the model is
called the 'Object-Capability' model and not the "Object-Access"
or "Object-Reference" model, and
3. The term "capability" binds explicitly to the whole history
of capability based systems. Of course this can cut two ways,
seeming to broaden the usage more than wanted in the subset that's
the "Object-capability" vs. the simple "Capability" model.
However, does using the "reference" term really help in that
regard? To me that term is even more ambiguous. At least the
"capability" term suggests the binding of designation and
permission. In that light the "Ojbect-Capability" definition
for a 'capability' can be seen as a refinement of the more
general "capability" definition.
I suppose we could try to use some sort of new term or
abbreviation, e.g. Ocap or OCapability or the like.
Such usage would seem a bit forced to me.
>(I have some reservation about whether this is consistent with the
>historical usage of "capability"; e.g. several systems have had
>"data capabilities". However, it is consistent with how "reference"
>is used in programming languages.)
To me whether one sees "data" capabilities is mostly a matter
of where you look. If you look at the serialized "off-line"
capabilities communicated between the E vats, are they "data"
capabilities? They seem so to me. Are these to be excluded
from the "reference" term or the "capability" term in our
definition? They communicate a permission, so I refer to them
as a "capability". To me a "capability" is defined by it's
function and not how it's implemented. Of course that's
why I suggested so many potential implementations for network
"capabilities" in the Managing Domains paper:
As I say there (to save people looking through the reference):
_________________________________________________________________
For our discussion it will be convenient to have a single term to
denote resource access. We will use the term capability [DeV66-3,
Eng72-10, Fab74-11, Lan75-17, LaS76-18, Wul74-28]. We say that a
process has a 'capability' to a resource if it has been authorized
access to the resource. A capability is thus a key that can unlock
access to a resource. We define the domain of a process to be the set
of capabilities that it possesses.
This use of the term capability is a generalization of the way it is
often used in the discussion of capability-list (C-list) OS's
[Lan75-17, LaS76-18, Wul74-28]. In C-list systems, capabilities do
authorize resource access, but the term is generally restricted to
refer to a specific form of capability implemented as some type of
pointer that is protected by the kernel of a stand-alone OS. In such
systems all communication and validation of capabilities (in this
restricted sense) is mediated by the system kernel. This centralized
approach to access control unfortunately does not extend well into a
distributed environment [Don76-5, Don79-6].
Our purpose here is to explore the types of protocols suitable for
capability passing and validation in a network OS. Our protocols must
allow serving processes to give out capabilities to potential users
in such a way that:
1. The capabilities can be validated when used as authorization
for service requests.
2. The capabilities can be communicated or passed between any two
processes that can communicate data.
______________________
In defining the "Object-capability" model, do we intend to exclude
distributed (network) systems where any notion of a "capability"
(communicated object reference) must necessarily be serialized
(data)?
Whether or no, I still argue in favor of using the term
"capability" vs. the "reference" term - once the capability
term is defined at the outset.
If we do intend to exclude serialized or capability as data
implementations, then I think perhaps we need another means.
I don't know how to do so with only functional requirements.
--Jed http://www.webstart.com/jed-signature.html
More information about the cap-talk
mailing list