[cap-talk] Ambient authority in DVH, PDP-1 supervisor, Multics, mutual suspicion

Jed Donnelley jed at nersc.gov
Tue Aug 1 17:59:32 EDT 2006

At 03:33 PM 7/30/2006, Charles Landau wrote:
>It may not be widely known that the Dennis and Van Horn paper,
>despite its brilliant formulation of capabilities, also made use of
>ambient authority...

In reading back through some of the early design documents on Multics, e.g.:

Introduction and Overview of the Multics System (Corbató)

it appears that the only access control imagined for at least the file system
was to allow sharing between users (people):

"Of considerable concern is the issue of privacy. 
Experience has shown that privacy and security 
are sensitive issues in a multi-user system where 
terminals are anonymously remote. For this 
reason, each user's files can be arranged to be 
completely private to him. In addition, a user 
may arrange to allow others to access his files 
selectively on a linking basis. The linking 
mechanism permits control over the degree of 
access one allows (e.g., a user may wish a file to be read but not written)."

I don't recall how that "linking mechanism" 
worked.  I know I'm being lazy, but if somebody 
remembers it and can briefly describe it I would 
find that helpful.  Everything I see about access 
control in Multics seems to use ACLs with people as subjects, e.g.:


I don't see anything in the Multics documentation 
about access control on a process bases or 
anything about communication of permissions 
(capabilities ala. Dennis and Van Horn) between 
processes.  This is why I argue that Multics 
"turned away" from object capabilities.  How much 
was actually known about the consequences of such 
a direction I don't know.  It seems clear that by 
the time of the RATS system at LLL in 1972-1973, 
object capabilities were available full blown.  I 
had always thought that since the RATS system was 
nominally considered a port of the PDP-1 
supervisor, then the PDP-1 supervisor must have 
had a basis in object capabilities (communicable 
permission tokens, no ambient authority).

I would like to know if that was true, and if so when and what happened to the:

"The meta-instruction
i := link <principal name>;

and this design principle:

"When the supervisor creates a computation on behalf of
a principal, it always places in the C-list of such a computation
a directory capability with an O indicator that
points to the principal's root directory. The principal is
then said to own this computation and each of its processes.
These processes are then permitted to exercise powers of
ownership with respect to objects owned by the principal."

from DVH?

There's quite a bit of time between the DVH paper in March of 1966
and where I heard about anything with the RATS system in 1973.
Was there somebody at MIT that picked up the "object capability"
thread - e.g. from DVH, from the early supervisor implementation,
etc. and purified it in some way to separate it from ambient authority
access control bases on principals (users - people)?

I notice that even in this implementation paper by Ackerman and Plummer
in 1967:


there's no mention of a "principal":  They do provide the "entry" mechanism:
Computations may define service subroutines
to be called by other computations by creating
an enter capability and granting it to the other
computations. The capability specifies the computation
to be entered and the starting address.
When a process invokes an enter capability, that
process is suspended (by the executive routine)
and a new process is started in the computation
being entered. A suspended process capability
is created in the C-list of the entered computation
and the service routine (in the entered
computation), may, by invoking this capability,
examine and modify the registers of the calling
process and do whatever is necessary to process
the request, finally executing a proceed meta instruction
to resume processing by the calling
process. The calling process may transmit a
capability from the C-list of its own computation
to the service routine. This is useful for
certain types of service routines, particularly
those involving I/O operations. A service routine
of this type may be reentrant and hence may be
simultaneously servicing requests from several
processes, although the process locking techniques
to be discussed later may be used to limit the
number of processes permitted in certain sections
of the routine at any one time. The ability to
have reentrant service routines is especially useful
for coding routines that take a long time,
such as a routine to take input from a typewriter
and put it in a file.

The notion in the above that the entered process may
"examine and modify" the registers of the calling
process seems to suggest that this isn't quite
communication between mutually suspicious processes.

I know the notion of mutual suspicion was published at least
by the Michael Schroeder thesis in 1972:



where he used the term "capability" in the object capability sense.

It seems that some time between 1966 and 1972 some thought must have
gone into using object capabilities as a means for enabling cooperation between
mutually suspicious processes.  I have an indirect message headed
toward Michael Schroeder on this topic.

--Jed http://www.webstart.com/jed/  

More information about the cap-talk mailing list