[cap-talk] Persistence as a category, danger, PLASH

[Jonathan S. Shapiro]

On Fri, 2008-03-14 at 12:02 +1000, James A. Donald wrote:
> All the more reason to make capabilities even more
> fragile - for example, the capability should expire if
> any of the relevant processes shut down.

James: In every capability system that I know about, two things are
true:

  1. Capabilities expire when the object that they name expires.

  2. Individual copies of capabilities expire when the process
     or object containing them expires. The storage goes away,
     and the capability residing in that storage consequently
     disappears.

I light of this, I'm not clear what new point you are trying to make
above.

> LAMP systems are able to run for months in part because
> they continually spawn new processes and shut them down...

What you are arguing for here -- and I agree with your point -- is a
form of temporal isolation. While *some* of the state in a given
transaction depends on earlier transactions (example: what you withdraw
from the bank today depends on what you put in yesterday), any such
"context spanning state" introduces the possibility that error may creep
forward from one operation into the next.

To manage this, we want to do several things:

  1. Clearly separate such "context spanning state" from all state
     that is transient to the transaction.

  2. Take a range of steps to validate and consistency check all
     context spanning state, both at the time of transaction and later.

  3. Take steps to ensure that context spanning state is recoverable.

  4. Take steps to ensure that all transient state is forcibly wiped
     out so that it cannot inadvertently influence later contexts.

There is an exception:

To the extent that every newly created context executes the same code
during its initialization phase, it is reasonable to bring a template
context up to the point where initialization is complete, pickle that,
and re-instantiate it multiple times in order to save the cost of
iterative re-initialization. This is an optimization on my statements
above, but it doesn't change the fundamental character of the defensive
strategy.

I don't think that any of this is disagreeing with what you said.


shap