[cap-talk] Persistence as a cap value (was: Re: ...PLASH discussion)

[Jonathan S. Shapiro]

On Thu, 2008-03-13 at 08:43 -0700, Jed Donnelley wrote:
> At 03:29 PM 3/12/2008, Karp, Alan H wrote:
> >Jed wrote:
> >...
> > > While I can understand the value of starting a system in a known
> > > consistent state, I find it difficult to appreciate the value of
> > > capabilities whose operation can be seemingly capriciously changed
> > > by a system restart.  To me persistence if only an issue because,
> > > while valuable, it may present some difficulties to implement.
> > >
> >The programmer decided which capabilities should survive a system 
> >restart for each application.  The system did nothing special to 
> >rebuild a consistent global state.
> 
> I wonder if you could give an example of a capability that made
> sense to issue/communicate as non-persistent?  To me it seems
> useless to even create such a capability as it may disappear
> before there is even a chance to use it - as a system can be
> restarted at any time.

The argument for revocation on restart is very straightforward:

In a networked capability system, a remote capability is generally
associated with an authenticated session. If the operation governed by
the capability motivates re-authentication on restart, it is entirely
sensible to revoke the cap. The problem is that you do not know who has
re-acquired control of the session, and to the session controller the
caps are merely data.

But it's more efficient to simply revoke the session.