Easy to understand protection

In CAL TSS, all protection is founded on one idea: possession of a pointer to an object (capability) grants access to the object as specified by the pointer. Two subprocesses within a single process have different access rights because they have access to different sets of pointers. In general, access rights are transferred from program to program by moving pointers. Access keys and locks are a somewhat different mechanism. However, they are implemented using the capability machinery, and possession of a capability for an access key is necessary to open a matching lock. Furthermore, even though an object in another directory may have a lock matching a given user's access key, the user must explicitly obtain a capability for the object (using his key) before he can access the object. A capability based protection system seems to provide features that are difficult to obtain in other systems, such as Multics. Two such features seem to be:

1)

The ability to provide for mutually suspicious subsystems within the same process;

2)

The ability for new layers of system to be constructed, which provide new virtual objects, and permit protection for these objects to be controlled using the same machinery as used for more basic objects.

CAL TSS provides for mutually suspicious subsystems simply by placing them in subprocesses neither of which is an ancestor of the other. One of these subprocesses may touch objects accessable to the other only through parameters passed in a call, or with the assistance of a common ancestor subprocess (presumably a trustworthy bystander). The addition to the disk/directory system of the ability to construct ``user'' disk/directory system types would have made it possible for new system layers to construct new types of virtual objects. (This facility was provided by the ECS system, and was used by the disk/directory system to provide disk/directory objects. It is a quite simple feature to implement.) Since capabilities for these new type objects could be placed in directories, access to them could be controlled in exactly the same ways as access is controlled to disk files and directories. (For example, this feature would have permitted nametags to be implemented by system code written upon the disk/directory system, rather than directly implemented in the disk/directory system.)