PREVIOUS
Sensory keys
A universal paradigm in software design is the linking together of data structures with pointers.
This idea is carried over into capability systems by using keys as pointers.
Consider a tree of nodes with pages at the leaves.
The nodes hold node keys and page keys.
To our knowledge, in previous capability-based systems a node key to the root node allowed the holder to peruse and modify the collection.
There was no “read-only” key to the structure.
A fetch key to the root node is too strong because it may be used to fetch a node key to a lower node which, in turn, may be used to change lower nodes of the tree.
To solve this problem KeyKOS provides sense keys to nodes.
A sense key is weaker than a fetch key.
A sense key appears to the holder as a fetch key except that any key delivered to the holder as a result of an invocation of a sense key is the sensory version of the key being fetched.
The sensory version of a node, sense, or fetch key to node N is the sense key to node N.
The sensory version of a segment key is a segment key without authority to invoke a segment keeper.
The sensory version of a page key is the read-only key to the same page.
If K is a number key or a key to one of the following objects then the sensory version of K is K:
- Discrim
- the Number Key Creator
- the Returner
The sensory version of other keys is the null key.
The important thing about a sense key is that it conveys no authority to influence a structure.
The holder of the sense key can browse through the structure but is unable to affect it, nor may a non-sensory key be obtained using a sense key.
If the structure holds page keys (a common situation) then those pages will be available for reading but not writing.
NEXT