[cap-talk] Objects and Facets

[Mark S. Miller]

David Hopwood wrote:
 >> My belief is that while the term "object" is a wonderful informal
 >> concept, it has no formal definition. Consider a start key to a
 >> process implementing an Ethernet socket. From the kernel's
 >> perspective, the start key is a facet of a process object, and an
 >> invocation of the key just delivers a message to the process.
 >
 > In terms of the object capability model, in this kind of system a
 > process implements multiple objects. There's no obstacle to formality
 > here.


I endorse everything in David's message. His stance on terminology clarifies 
and accurately reflects how these terms are used at erights.org, in various 
papers I've co-authored, and in the "object-capability model" as stated in my 
thesis. I specifically set out to state a model general enough to describe 
both existing object-capability operating systems and object-capability 
programming languages.

In describing an object-capability system, the use of "object" as defined by 
this model, surprisingly (to me) agrees both with the definition of "object" 
as used by object programming languages (an encapsulated combination of state 
and behavior) and the definition of "object" in access control.

Regarding access control in general, in Section 8.1 p58 I state:

# By object, we mean the finest-grain unit to which separate direct access
# rights may be provided, such as a file, a memory page, or another subject,
# depending on the system. Without loss of generality, we model restricted
# access to an object, such as read-only access to /etc/passwd, as simple
# access to another object whose behavior embodies the restriction, such as
# access to the read-only facet of /etc/passwd which responds only to queries.


The object-capability model is explained starting in section 9.1 p64. There we 
state:

* An object is either a primitive or an instance. Later, we explain three
   kinds of primitives: data, devices, and loaders. Data is immutable.
* An instance is a combination of code and state. We say it is an instance of
   the behavior described by its code. For example, in an operating system
   context, we say a process is an instance of its program. In a lexically
   scoped lambda language, a closure is an instance of its lambda expression.
* A reference provides access to an object, indivisibly combining designation
   of the object, the permission to access it, and the means to access it.
* A capability is a reference to non-data.


Unfortunately, the "process" example in my text above seems to support the 
other naming perspective that's been mentioned recently on this list 
(state-holder == object). David's note clarifies this issue. In KeyKOS, for 
example, each distinct start key to the same domain -- distinguished by its 
so-called data byte (i.e., what EROS more clearly calls the "facet id") -- is 
a capability to a different object. The object designated by a given start key 
is the combination of the process's state with the behavior triggered by 
sending messages to *this* start key. Since the same process will respond 
differently to the same messages as sent to a different start key, different 
start keys designate different objects.


For descriptive purposes, we often want to aggregate several objects into one 
composite. Such aggregation is purely subjective. Which aggregations we should 
employ depends on the descriptive purposes at hand. In KeyKOS, a natural 
descriptive aggregate for many purposes is the process (domain) together with 
all the keys which designate the root node of that process (all start keys, 
domain key, node key). Given some descriptive composite, those objects within 
the composite which are potentially designatable from outside the composite 
are facets of the composite. (More on this in Section 6.2 p42.)

Every facet is an object. However, when speaking at the atomic level of 
description, there are only objects and references. The term facet is used 
only in relation to a composite. It is nonsensical to speak of a "facet of an 
object". Rather, one only has facets of composites. A KeyKOS domain is a 
composite. A start key to a particular domain with data byte "3" is a 
capability to a facet of this domain-composite.

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM