The Application Design’s Perspective on Capabilities

We examine here the discipline of capability design from the perspective of the designer of an application.

The significant feature of capability design is that access to the many parts of a complex application are accessible by just those people and programs required by the application’s nature.

This is in contrast to the situation in Unix where names of application components must appear in directories in order that other application components be able to accesses them. Unix is typical in this regard. Very often these directories are accessed by people who know the root password. If the applications are few and simple enough then few people need to know the root password and these application components are safe enough. In practice, however, it is often the case that the collective complexity of the applications require several people to access the root directory. This situation limits the stability of machines with many complex applications.

The decomposition of very large applications into independent components leads to the same problems: Unix does not provide sufficient separation between components.

There are several resource classes in Unix with insufficiently developed ownership properties.

Ports are first-come, first-served. Application (and deamon) initiation upon system startup mostly controls who gets what ports. There is little support for discovering which applications are listening on what ports.
Named pipes ...

Material in italics are claims about Unix that I think are true but I would like confirmation (or refutation) by someone who knows more than me.

The large Unix application must contend with the name space provided by the Unix file system in order to carry data from:

one day (system boot) to the next,
one address space to another,
the application to other applications.

The elements named in this space may be files, pipes or other system components.

The rules for access to this name space are not well designed to make large applications able to achieve durable and robust service.

There are no ways to guarantee an amount of space or time for a critical application. There are a few piecemeal limitations that can be put on the other Unix applications which may help.

In a system such as KeyKOS one can build sub-system components and arrange that just those other components that require access have that access.