Providing Classic Access Control

Here I explore providing with capabilities, access control reminiscent of the access control lists of some conventional operating systems.

The access control list can be changed to add or delete access by a principal P to a particular file F. With capabilities this may be partially modeled by creating an indirection object N that will hold a capability to F while providing access is desired and holding nothing when it is not. Two capabilities to N arise as it is created:

Ns, the service capability which lets its holder define N’s meaning,
Nu, the usage capability which appears to its holder, to be a file capability.

Nu is transmitted to P but Ns is retained by F’s owner. This pattern is familiar to programmers except for the inability to fetch the file pointer using Nu.

(In Keykos F would be a segment and N would be a node. Ns is the node key and Nu is a segment key to N.)

When it is desired to allow access by P to F, F’s owner puts the capability to F in N by invoking Ns. By placing a null capability in N access by P to F is temporarily or permanently revoked. (Better service to P might be provided by putting a capability to a static but stale version of F in N while embargoed information is developed in F.)

Subtle differences remain between this form of access control and classic ACLs. I will argue that while not equivalent, they generally favor the form provided by capabilities. Access by a principal to a file depends on how access was acquired. If P₁ conveys rescindable access to P₂ and then P₂ passes that to P₃, capability discipline would appear weaker than access lists for the owner had not intended to provide access to P₃. With access lists, however, P₂ could still pass the file’s content to P₃ and would arguable seem likely to do so under similar circumstances. The extra power of access lists seems empty. Note that either of these cases requires P₂’s ability to deliver to P₃. Capability discipline can deny this ability.

The ostensible reason to rescind P₂’s access, is to hide information subsequently put into the file. Again the information protection is the same, for P₃ also looses access to this new data. If P₂ is a contractor whose job is defined by the content of the file is should not concern P₁ that P₂ has a sub-contractor. If P₁ wants to guard the disemination of the file’s content then confinement can provide this with capabilities but not, as far as I can see, with access lists. With confinement P₁ need not even trust P₂ with the file or its content.