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.
I agree that the capabilities can be created only when needed, and that approach makes sense in many environments. However, in situations where latency is important, it may make sense to create the capability when the object is created or when the system has some cycles to spare. We have a counter example to the statement that most capabilities never need to be created. Our e-speak Virtual File System must issue capabilities for each access right of each file it controls. (Here's where wildcards are used.) While any client over any session may need only a few capabilities, over time a substantial fraction of the possibilities will end up being created, and each client may end up holding a substantial fraction of them. This number can be quite large if wildcards are not used for the name of the object.
> -----Original Message-----
> From: Norman Hardy [mailto:norm@netcom.com]
> Sent: Monday, July 03, 2000 4:23 PM
> To: Karp, Alan; 'e-lang@eros-os.org'
> Subject: RE: Split Capabilities: Making Capabilities Scale
>
>
> At 8:45 -0700 00/06/30, Karp, Alan wrote:
> >> -----Original Message-----
> >> From: Norman Hardy [mailto:norm@netcom.com]
> >> Sent: Thursday, June 29, 2000 6:41 PM
> >> To: Karp, Alan; 'e-lang@eros-os.org'
> >> Subject: RE: Split Capabilities: Making Capabilities Scale
> >>
> >> (snip)
> >>
> >> Capabilities are a bit like floating point values. You do not
> >> need enough
> >> storage to keep every possible floating point value even
> >> though in general
> >> a particular computation may in principle use any possible
> >> floating point
> >> number. As with fp numbers you may discard them and reproduce
> >> them upon
> >> demand. Most Keykos objects were created and destroyed with
> >> few of the
> >> possible capabilities for them ever having existed. Many (most?)
> >> capabilities were created, passed, used and then discarded in
> >> less than a
> >> second.
> >>
> >> Your pattern may have other strengths, however.
> >>
> >
> >Many cryptographically secure capabilities are not
> lightweight enough to be
> >treated so cavalierly. For example, the SPKI certificates
> used in e-speak
> >Beta 3.0 carry quite a bit of information, and delegating a
> subset of the
> >rights is a non-trivial operation. We were quite latency
> sensitive in the
> >early days of e-speak, sub millisecond latency being our
> goal. I don't
> >think that's possible if capability construction is in the
> critical path.
> >
> >There is another difference here. Most Keykos objects were transient
> >instantiations. Many if not most of the services and
> resources in e-speak
> >are persistent or at least long-lived. Examples include
> files, SAP, and the
> >like. Hence, it is not unlikely that most combinations of
> access rights
> >will be needed over the lifetime of an e-speak resource.
>
> I agree that crypto capabilities are expensive to produce,
> but that may be
> reason to postpone creating them until they are actually
> needed. Reading
> Jonathan's response reminds me that I don't understand you wild card
> scheme, which is probably my fault. Also what Johnathan says of
> capabilities is true of Keykos in that there are typically only two or
> three capabilities possible to a given object, only one of
> which may ever
> be created for that particular object. Each capability will
> have its own
> methods (we called them orders). More esoteric capabilities
> to some object
> are likely invented after the the object's code is frozen and the new
> capability is via a front end.
> Norman Hardy <http://www.mediacity.com/~norm>
>