<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jonathan S. Shapiro wrote:
<blockquote cite="mid1186084661.25316.81.camel@shap.om-md.eros-os.com"
type="cite">
<pre wrap="">On Thu, 2007-08-02 at 11:59 -0700, Jed Donnelley wrote:
</pre>
...
<blockquote type="cite">
<pre wrap="">
It's certainly true that Mach (and I believe DEMOS at least
falls into the same category, perhaps Chorus?) referred to
their protected objects as "port"s. This suggests more of
a "network address" sort of use...
</pre>
</blockquote>
<pre wrap=""><!---->
You are correct. A mach thread may have many receive ports, enabling it
to use ports to name objects. Further, it can aggregate these into sets
so that it can do "receive on any" operations.
However, Mach is at best an impure capability system. There exist system
calls other than "invoke capability", and the Mach documentation is very
careful to characterize it as "capability-like" (their term).
</pre>
</blockquote>
Good term, "capability-like". Still, I think your more important
criticism of<br>
Mach and Chorus regarding capabilities is the durability point that you
make<br>
below:<br>
<blockquote cite="mid1186084661.25316.81.camel@shap.om-md.eros-os.com"
type="cite">
<pre wrap="">My impression from a quick review of the Chorus docs is that Chorus
ports name processes. A chorus "capability" (unprotected, though they
thought otherwise) names a port and gives an object ID.
It is not clear how the Chorus "capability" notion corresponds to
capabilities, and it might be good to check before engendering
confusion.
</pre>
<blockquote type="cite">
<pre wrap="">Perhaps what is more important for such systems is
how they use their protected objects in practice.
I often use the file system as an important test case.
Does Mach (DEMOS, Chorus?) use separate "port"s
for each file or do they somehow use a smaller number
of ports and include designation information as data?
</pre>
</blockquote>
<pre wrap=""><!---->
I suspect so, but more importantly: Mach uses principal-based access
control, because ports do not survive system restart. Chorus likewise.
</pre>
</blockquote>
You've definitely hit a critical point there. Whether in some sense<br>
'we' want to refer to such systems as "capability" systems (e.g. because<br>
they can provide a POLA environment for running programs - without<br>
access to the ACL interface), I certainly consider them as dysfunctional<br>
regarding their use of capabilities for access control since they have
to<br>
start from a non-capability base (e.g. users/ACLs) with every system<br>
restart.<br>
<br>
I admit that I've never seen any sort of a Mach interface other than<br>
Unix, but when I consider that network server for Mach:<br>
<br>
R. D. Sansom, D. P. Julin, and R. F. Rashid. Extending a<br>
Capability Based System into a Network Environment. In<br>
Proc. 1986 ACM SIGCOMM Conference, pages 265–274,<br>
Aug. 1986.<br>
<br>
it makes me think of the DCCS and I then jump to durable<br>
(is that the right term?) capabilities - which is completely erroneous.<br>
(Note the use of the "capability" term in the above title).<br>
<br>
If these sorts of systems are to be considered 'capability' systems,<br>
then I certainly think they need a sub category of their own,<br>
perhaps with **s next to it.<br>
<br>
If we do that, however, then I guess Unix has to be considered<br>
a "capability"** system, as Unix open file descriptors can<br>
be communicated over pipes and can act in some sense as<br>
capabilities - as with Mach.<br>
<br>
I'm strongly persuaded. Some of the Mach documentation may have<br>
claimed the "capability" term (perhaps when it was still a bit more<br>
fashionable, particularly at CMU after the Hydra legacy, before<br>
the TCSEC/Orange Book/Rainbow onslaught), but I consider Mach<br>
to be negligibly 'capability', so I think Mach should generally<br>
be left out of any such list of capability systems. They might<br>
be relieved to hear such a 'pronouncement.'<br>
<br>
However, I note that if we take that tact then we significantly<br>
thin the ranks of 'capability' systems. By that criteria I think<br>
we must eliminate all the language based systems, Emerald,<br>
Network Objects, and E just as examples that come to mind?<br>
<br>
In that case which of these systems provide only non-durable<br>
capabilities? Let me make a first guess pass with the *****s.<br>
Those where I'm pretty sure have durable capabilities are<br>
indicated with <<<<<<<<s. The ??????s are
obvious:<br>
<br>
<pre wrap="">1959: Rice University Computer *****? Not caps I'm pretty sure.
1961: B5000 - Burroughs ******** (not caps at all really
despite what you may have heard)
1964: Dennis & Van Horn - MIT ****** (a design, not a system)
---------------------------------------------------
1966: PDP-1 Supervisor - MIT <<<<<<<<<<<<
1967: Magic Number Machine - University of Chicago *****?????
1968: CAL-TSS - Berkeley ***** never finished, so...
1969: System 250 - Plessey Corporation ***********
1969: BCC Model 1: Berkeley Computer Corporation *******
1970: Gendanken - Argonne National Laboratories/ Berkeley ????
1970: CAP - Cambridge University ?????
1971: Future System Project - IBM ?????
1971: Project SUE - University of Toronto ?????
1971: Hydra - Carnegie Mellon <<<<<<????
1972: RATS - Lawrence Livermore <<<<<<<<
1973: System/38 - IBM ?????
1973: Actors - MIT *******
1973: PSOS - SRI ******* (abandoned capabilities)
----------------------------------------------------
1975: StarOS - Carnegie Mellon <<<<<????
1975: GNOSIS/KeyKOS - Tymshare/Key Logic <<<<<<<<
1976: Monads - Monash University <<<<<<<
1977: Demos - Los Alamos *******
1978: NLTSS - Lawrence Livermore <<<<<<<
1979: Eden Project - University of Washington ??????
1979: Chorus - INRIA/Chorus Systemes ******
1980: SWARD - IBM ?????
1980: SODS/OS - University of Delaware ?????
1980: PDP 11 operating system - University of Texas
Huh??? ??????
1980: Path Pascal - NASA ******
1981: Amoeba - Free University Amsterdam <<<<<<<<
1981: Flex - Royal Signals and Radar Establishment (RSRE) ?????
1981: Accent - Carnegie Mellon ?????
1981: iAPX 432 - Intel *****
1982: Password-Capability System - Monash University <<<<<<<<<
1982: Cambridge Distributed Computing System - Cambridge University ?????
1984: SCAP - Cambridge University ???????
-------------------------------------------------------------
1985: Mach - Carnegie Mellon *********
1985: Emerald - University of Washington *********
1988: SMITE - RSRE ?????
1990: EROS - U Penn (wow, I didn't know EROS started so early) <<<<<<<
1990: Joule - Los Altos ????? (Los Altos??)
1992: Mungi - New South Wales ?????
1994: Grasshopper - University of Sydney ?????
-------------------------------------
1995: Client Utility - HP Labs ?????
1995: Original-E - Electric Communities *****
1996: W7 - MIT *****
1996: Oviedo3 - Oviedo University (Spain) ?????
1997: SLK/J-Kernel Cornel ?????
1998: SpeedOS - University of Ulm ?????
1999: E Language *****
The above are my best guesses. That leaves a rather
sparse field if we were to remove both the ????s and
the ****s and leave only those with <<<<<<<s that I am
pretty sure are capability systems. 9 systems only
that start with <<<<<<<s. 18 more if you include
those that I am most ignorant of, those that start
with ?????? I expect most of those ??????s will
drop out by the somewhat tighter criteria above.
</pre>
--Jed <a class="moz-txt-link-freetext" href="http://www.webstart.com/jed/">http://www.webstart.com/jed/</a><br>
</body>
</html>