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

[Jed Donnelley]

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.

Here's a "proof" (using the above thinking) that all capabilities
should be persistent:
__________
If having a capability disappear before it's first intended use wouldn't
cause a problem, then don't create/issue the capability.

If having a capability disappear before it's first intended use
would cause a problem, then it must be issued as persistent.  (e.g.
and then revoked when it's absence would no longer cause a problem).

Therefore in any case capabilities should be issued as persistent.
__________

I'm interested to hear what people feel is erroneous about
the above reasoning.  I guess the thinking must be something
along the lines of: If the process that received the capability
is destroyed with the capability then there is no loss?
However, even in that case I question: Why even create the
capability to begin with?  Can I guess this must come from
the try, try again school?  That is, you keep trying to issue
and use the capability until something needed gets done?
Can I also guess that there is something more permanent
about the ultimate effect that needed doing to begin with?

I think there must be something in here about capabilities
that have the same "persistence" as the processes that are
using them?

Perhaps I should be clear that by "persistent" I don't mean
"permanent".  All I mean is capabilities that aren't capriciously
destroyed by a system restart that can happen at any time.  Even
capabilities that can be revoked (e.g. Horton) are still
'persistent'.

I'll also note that this whole recent discussion begs my initial
focus regarding capabilities as the means for long term access
control - e.g. as between people.  Clearly non-persistent
capabilities are useless as a means for long term access control
for people (e.g. why Mach ports must be subsumed by some another
access control scheme like Unix "ACLs") as they can be capriciously
lost at any time - defeating the whole purpose of their use as
vectors for long term access control management between people.

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