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

[Jed Donnelley]

At 04:19 AM 3/12/2008, Rob Meijer wrote:
>On Wed, March 12, 2008 07:27, Jed Donnelley wrote:
> > For me the most natural form of access delegation
> > is via a reference in a message.  Is that because I
> > think like a program ;-) ?  I don't think so, but
> > then perhaps I'm not the best judge.  I believe that
> > such a delegation mechanism is just the most parsimonious
> > and "natural".  I say exactly what I'm delegating (access
> > to whatever the reference refers to) and "who" I'm
> > delegating it to - the receiver of the message.  Sort
> > of like sending a physical key in a postal letter.
>
>I completely agree with this part.

Glad to hear it.

> > In some sense the receiver of any message is always
> > a program, but I may know that by doing a delegation
> > by a program acting on my behalf (the sender) to a
> > particular receiver that the net effect is a delegation
> > of access to some person.  A persistent delegation of
> > such an access.  To me sending an email that includes
> > a 'capability' (e.g. a Webkey) is a very natural form
> > of delegation, which is in turn what seems to me to
> > be a very simple and easily understood for of access
> > control "management" - at least for the initial
> > delegation, revocation or after the fact (of
> > delegation) management is another issue (e.g. a
> > Horton UI).
>
>The main issue here is I think that delegation can
>only be natually persistent if 'all' concerned objects are
>naturally persistent.
>If a system reboots, the people involved remain persistent,
>the program code remains persistent, but the programs involved
>are new instances of this code, possibly started with different parameters
>and/or run in an other context. The notion of a process being an
>incarnation of a 'persistent' program is therefore unnatural, and thus I
>feel persistent delegation is not directly suitable.

When you say "not directly suitable" in the above, do you mean
"not readily achievable" (i.e. this is an implementation issue)
or do you mean "inappropriate" (namely there is something about
persistent objects that would cause a problem)?

In the former case I believe we have many instances of
capability systems with persistent objects, so it is
certainly possible to achieve such persistence - if such
persistence has value (as I believe it does).

I'm particularly interested to hear from the people focused
on the language area regarding this topic.  Perhaps if this
thread has any energy/legs it would be helpful to share it with
elang?

>As I am trying to do in my MinorFs project, I do however feel that a
>(pseudo) persistent process concept would allow the processes to act as
>naturally persistent objects, thus enabling persistent delegation.

I believe I understand the above - though the use of the qualifier
"pseudo" seems a bit odd to me.  If there is something worth expanding
on there I'd be interested to hear.  However, regarding:

>Without such a construct I feel persistent delegation with intervention of
>non persistent processes seems to be pushing to much dangerous powers to
>the people using the system, what IMO could very easily be bad for POLA.

I'm afraid I don't understand what you mean by the above.  Let me give
a brief example from a system I was involved in, the NLTSS system,
and see if perhaps you can contrast it with your concerns above.

As with any modern computer system, when the NLTSS system rebooted
it had to rebuild it's state in memory, including all it's processes.
It may have been able to recover what was in memory or not (power
loss).  Our philosophy was that disk file storage was our 'permanent'
storage and we based our object persistence on that (though of course
we required the usual backups, etc. to support disk "permanence").  As
such the file server was a key component.  The file server ran off meta
data in the form of file "headers" that were cached into the memory
of the process server, but nominally stored also on disk in an
area that could be recovered during a "cold" (loss of memory) restart.

The Process server and other servers build their persistent objects
on files.  The process server stored process state nominally in
files - including the process header (register set, state, etc.) -
which were nominally on disk and just cached into memory.

Of course during a clean shutdown of such a system everything can
be cleanly written to disk and everything is hunky dory.  When the
system is started again everything can be pulled in from disk and
off things go.  However, there are various situations where one is
forced into non-clean system shutdowns such as software faults and
hardware faults (including loss of power).

For these non-clean shutdowns we had some "warmstart" mechanisms
that would basically paw through what was in memory and recover
what it could - checking for and restoring consistent state
as possible.  I won't get into the details.  As I hope one
can imagine we had some levels of "warmness" (e.g. "hot" start,
etc.) that we could use and sometimes needed to recover system
state from colder and colder disk storage as required.

Our object servers were responsible for managing their own
"header" and direct state with a similar disk first (i.e.
based on permanent store) approach.  They had to assume that
whatever they had in memory could at any time be lost
(e.g. power loss), in which case they would do their best
to recover objects from longer term disk (to them file)
storage.

It's clear that with such an approach some amount of
object state will be lost when memory is lost.  This seems
inevitable to me, which is why I'm particularly interested
to hear from the language folks about their approach to
persistence.

>So my (initial) stand on this topic would currently be 'dont try to do
>persistent delegation with non persistent processes'.
>
>I am very interested to hear alternative views on this.

Well, you heard my approach above.  We did have "persistent"
processes, but they were subject to memory loss/reset
(i.e. recovery from an older disk version) at any time,
as seems to me to be the inevitable case with computer
systems - at least with solid state memories.  Object
servers were responsible for constructing their persistent
objects around persistent storage ("file" storage), but
even for these of course cached versions could be lost
and effectively reset to previous state stored on disk.

As noted above, I'm most interested to hear from the language
folks in this area.

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