> -----Original Message-----
> From: Norman Hardy [mailto:norm@netcom.com]
> Sent: Wednesday, July 05, 2000 7:50 PM
> To: Karp, Alan; 'e-lang@eros-os.org'
> Subject: RE: Split Capabilities: Making Capabilities Scale
>
>
> 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>
>
Very interesting. Not the hierarchy; I think they're dangerous when used in capabilities to denote groups of objects. The interesting part is the user's directory. It's almost exactly the e-speak Protection Domain, an e-speak resource which defines the part of the universe accessible to the user. It contains the e-speak root name frame, which defines the user's name space, and a mandatory key ring, basically a set of capabilities that get presented on every request. In general, there are capabilities on this key ring that the user cannot remove. This latter feature enables us to enforce "negative permissions", capabilities that deny access to certain resources.