[cap-talk] Persistence as a cap value

[Karp, Alan H]

In reference to what Jed wrote:

Client Utility (CU) was a very different kind of capability system, probably because I had never heard of capabilities when we came up with it.  I think Jed's confusion may stem from applying a more conventional model to my comments.

Let me briefly summarize CU.  Everything was a resource, and every resource had an entry in the CU repository consisting of a bunch of metadata.  Every entry had a unique handle, and handles were never reused.  Each process had a c-list, which we treated as a namespace.  Each namespace was embodied as a hash table (actually multiple tables) with a string as the key (corresponding to the c-list index) and one or more repository handles (corresponding to the capability) as the corresponding value.  Sending a capability involved including the string in a message, which resulted in the corresponding mapping appearing in the recipient's namespace.  Removing an entry from the repository invalidated all mappings to that repository handle.

Clients had to treat all capabilities as if they could vanish at any time.  (Isn't that the same as an ocap that can be revoked at any time?)  That's why we allowed multiple repository handles per string; if the first one didn't work, try the next one.  Transient capabiliities presented no special problems.  However, the metadata associated with a repository entry was between 100 B and 1-4 KB.  Transient capabilities were a convenient way to clean up the repository.  They were removed when the client that created them exited.
> >
> >Jonathan's example of a remote user is one.  That user can create
> >transient resources (think temp files) and their corresponding
> >capabilities that all vanish when the connection is broken.  Those
> >capabilities are useful to that client even if they're not
> sent to anyone else.
>
> Sorry, but I don't understand the value of the above example.
>
> I believe temp files (if used reasonably) fall into the category of
> tying the resource that only lasts until a restart with a process
> with the same property.  If the program runs and generates a
> temp file and the system restarts before the program outputs
> to permanent files, everything is lost.  You don't have to
> clean up the "temp" files is the only value I see there.
>
You also don't have to clean up capabilities to non-existent resources that the program would otherwise have when it restarted.
>
> I'm sorry, but I may need some more explanation to understand
> the above example.  For example, a connection can be lost without
> a system restart (e.g. network partition or timeout).  In that
> case I guess (from the above) that capabilities are invalidated,
> but not by a system restart.  The above suggests another sort
> of non persistent capability tied to connection longevity.
>
Client utility had two kinds of resources, persistent and transient, the choice specified when registering the resource in the CU repository.  Guest users could only create transient resources and capabilities to them, which lasted only as long as the corresponding client ran.  The client automatically exited when the connection to a remote guest was lost.  The guest would have to rebuild its state if it chose to reconnect, but we didn't need a heuristic for how long to hold onto the repository entries.
>
> >Transient capabilities are also useful for the recipient.  In Client
> >Utility, the c-list was actually stored in a set of "frames".  A
> >received capability stored in a non-persistent frame would not
> >appear in the client's c-list after the frame vanished.  That
> >allowed a programmer to control the permission state when the
> >program was restarted.
>
>
> And if the capability was communicated before the frame vanished?
>
Then it could continue to be used by the recipient.  How long depended on whether it was declared to be a persistent capability or a transient one.  The transient one would be destroyed whent the client that created it exited.  However, even a persistent capability could be destroyed, so clients had to be prepared to deal with dead references anyway.
>
> Hmmm.  Just by the constraint of my question, if the
> capabilities disappear before the processes, then a process may
> access an invalid capability - seemingly unnecessarily?

Which we explicitly accounted for because a remote resource could become unavailable at any time.  The name binding allowed us to specify alternates just in case.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp