Capabilities support custom security policies.

Unix and most of its contemporaries provide a mechanism to describe who should be able to access what files. This mechanism decrees three levels of community, self, group and all. There is no simple way to cope when the group is too large and yet a file must be shared. The mechanism is inflexible and not user replaceable.

It might seem impossible for a system to provide flexible security policy for who is to say which policy applies to a particular file. In capability systems the natural answer is that the creator of a file, or other object, says who has access to the file; the creator can deliver a capability for the file to which ever security regimes he chooses. He can share or create his own multi level directory structure if that meets his needs. The entire factory design is an example of security policy implemented entirely in user code—code that is itself subject to capability discipline—code that need be trusted by only those that need its services.

Some formal modelers argue about what security policies can be provided by the raw kernel function that is not extendable by the user. They conclude that capabilities cannot confine. There is perhaps an implicit assumption that there can be within one system just one fixed body of code responsible for security and this assumption precludes solutions, such as the factory, that is implemented outside that fixed body. This is reminiscent of the some early timesharing systems that supported just one computer language. They were not rich enough to provide a place to install programs such as compilers for alternate languages. I think that these models speak as if the access control lists are controlled directly by the user and not indirectly by system code, which incidentally, is actually user replaceable.

In KeyKos we used a simple graph of directories that suited the trust and responsibility purposes of our development group. The general directory object is a mutable map from strings to capabilities. Each user with a password to the system has a directory that holds his private capabilities. Another directory, SYS, holds the common “widely held” capabilities and its contents were documented. A user’s private directory would most likely hold a capability to SYS. There is no hierarchy to these directories but the command language supports strings separated by dots to reach thru a sequence of directories.

Presence in a directory does not serve to reserve space on a disk as it does in Unix where files exist only while they are accessible via some directory. Space is reclaimed thru other mechanisms.

Where programs in Unix must access files via their string name, programs in capability systems normally access files by virtue of already holding a capability to them, perhaps as a factory component. The capability stands in for the string name throughout the construction of the program. This early binding is impossible when the file is newer than the program. In such cases a node (capability segment) may be created along with the program. The program fetches a capability from the node when it is time to access the file. A capability to deposit into the node is sent to whom ever is responsible for producing the file and the capability thereto.