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>