Split Capabilities: Making Capabilities Scale

[Norman Hardy]

At 16:54 -0700 00/07/05, Karp, Alan wrote:
>Sorry, I should have been more explicit when I talked about wildcarding.
>I'm talking about wildcarding the name of the object, not the users.  I was
>thinking of the file system example where the objects have names that denote
>some function or connote a relationship with other objects, such as files in
>a subdirectory.  In that case, you can grant a permission to a group of
>files using a wildcard.  Examples would be /u/ahk/bin/* or /u/ahk/bin/*.exe
>or /u/ahk/bin/calc.*.  (Most capability systems are controlling objects that
>have names that are, for all practical purposes, random numbers.  In such
>systems, wildcarding the object names is simply not an option.)  Clearly,
>capabilities using wildcards to name objects can cause problems if I don't
>remember them all.  For example, I issued a capability naming
>/u/ahk/bin/calc.* so people could use my calculator and read the
>documentation.  If I later forget this fact and put my source code named
>calc.py in that directory, I will be granting them access to my souce code,
>something I may not have wanted to do.

By way of contrast
<http://www.mediacity.com/~norm/CapTheory/KK/CLI.html> is a brief note
on directory hierarchies and non-hierarchies in Keykos.
Directories were objects themselves and were accessed by
capabilities which could be distributed to others for sharing.
Function such as "/u/ahk/bin/*.exe" could be had by front end code
that behaved like a directory while hiding names that did not conform.
(I am not saying that that is better.)
Norman Hardy  <http://www.mediacity.com/~norm>