[cap-talk] Client Utility notes (was: Re: Persistence as a cap value)

[Jed Donnelley]

At 05:38 PM 3/14/2008, Karp, Alan H wrote:
>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.

Thanks Alan.  The above was quite helpful.  I hope the changed subject
for this reply will help me find the above next time I'm puzzled by
something relating to Client Utility.

> > >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.

So this is one of those cases where the capability and the
object and apparently the process (the VM the program runs
in) disappear at the same time.  Non persistent capabilities
make perfect sense under such circumstances.

> > 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.

After a system restart presumably everything had to be rebuilt
from the available persistent resources.  Did any capabilities
to them get rebuilt at that time or were they also persistent?

> > >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.

When a Client Utility system was restarted I presume that
all user state was recreated from persistent resources
(a tautology, but just checking) *and* persistent
capabilities?  That is, unlike a system like Mach,
the Client Utility system didn't depend on a persistent
set of resources and access control metadata for them
that was independent of its capability structure?

--Jed  http://www.webstart.com/jed-signature.html