[cap-talk] Capability-based Projects - theory vs. practice

Thu Aug 2 21:52:45 EDT 2007

Jonathan S. Shapiro wrote:
> On Thu, 2007-08-02 at 11:59 -0700, Jed Donnelley wrote:
>   
> ...
>> 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...
>>     
>
> 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).
>
>   
Good term, "capability-like".  Still, I think your more important 
criticism of
Mach and Chorus regarding capabilities is the durability point that you make
below:
> 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.
>
>   
>> 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?
>>     
>
> I suspect so, but more importantly: Mach uses principal-based access
> control, because ports do not survive system restart. Chorus likewise.
>   
You've definitely hit a critical point there.  Whether in some sense
'we' want to refer to such systems as "capability" systems (e.g. because
they can provide a POLA environment for running programs - without
access to the ACL interface), I certainly consider them as dysfunctional
regarding their use of capabilities for access control since they have to
start from a non-capability base (e.g. users/ACLs) with every system
restart.

I admit that I've never seen any sort of a Mach interface other than
Unix, but when I consider that network server for Mach:

R. D. Sansom, D. P. Julin, and R. F. Rashid. Extending a
Capability Based System into a Network Environment. In
Proc. 1986 ACM SIGCOMM Conference, pages 265--274,
Aug. 1986.

it makes me think of the DCCS and I then jump to durable
(is that the right term?) capabilities - which is completely erroneous.
(Note the use of the "capability" term in the above title).

If these sorts of systems are to be considered 'capability' systems,
then I certainly think they need a sub category of their own,
perhaps with **s next to it.

If we do that, however, then I guess Unix has to be considered
a "capability"** system, as Unix open file descriptors can
be communicated over pipes and can act in some sense as
capabilities - as with Mach.

I'm strongly persuaded.  Some of the Mach documentation may have
claimed the "capability" term (perhaps when it was still a bit more
fashionable, particularly at CMU after the Hydra legacy, before
the TCSEC/Orange Book/Rainbow onslaught), but I consider Mach
to be negligibly 'capability', so I think Mach should generally
be left out of any such list of capability systems.  They might
be relieved to hear such a 'pronouncement.'

However, I note that if we take that tact then we significantly
thin the ranks of 'capability' systems.  By that criteria I think
we must eliminate all the language based systems, Emerald,
Network Objects, and E just as examples that come to mind?

In that case which of these systems provide only non-durable
capabilities?  Let me make a first guess pass with the *****s.
Those where I'm pretty sure have durable capabilities are
indicated with <<<<<<<<s.  The ??????s are obvious:

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.

--Jed   http://www.webstart.com/jed/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20070802/91b7be21/attachment.html 