[cap-talk] Persistence as a category, danger, PLASH (was: as a cap value)

[Jed Donnelley]

cap-talk,

I've come to an understanding (probably repeated from
many times in the past) that I hope we can agree to enshrine
(e.g. on Wikipedia) so as to not lose again - that is if
you agree ;-)

It seems to me there is a category of capability systems
where non-persistence makes perfect sense.  These are
systems where capabilities are *only* used as vectors
of authority in processes that will be destroyed (and
not recovered) on a system restart.  For such systems
(I include PLASH, Mach, and many others) there is no
added value with capability persistence, in fact it's
difficult to imagine why or how one would even try.

In years past the "capabilities" in such systems I
believe were often (generally?) referred to as "Port"s.
Demos also fit into this category.  There were
others.

One only needs to start considering persistence if
there is some way to store capabilities between system
restarts.  In systems with such persistent (or at
least restart de coupled) capability storage I still
think my argument that all capabilities should be
persistent applies, so I'm again interested in Alan's
e-speak/Client Utility system - as I'm not sure which
category it fits into.

One thing I will mention about these non-persistent
(Port?) systems is that I don't believe they substantively
solve any "danger" aspect of capabilities.  Even though
capabilities may disappear on a system restart, that is
no reason to assume that they are substantially less
"dangerous".  Systems may not restart for a very long
time (months, years?).

Let me use PLASH as an example.  I'm only reasoning
at a high level from the notion that PLASH uses
Unix open file descriptors as "capabilities".
Given that architecture, I'll point out that
a Trojan horse can in principle send such an
open file descriptor to another process (e.g.
another user's process) that can then be used,
possibly inappropriately, until the next system
restart.

I believe that for safety PLASH should close open
file descriptors ("revoking" the 'capabilities') when
a run application terminates or is terminated.

Does it (Mark?)?

In a system where capabilities can persist (e.g.
either stored in files or where processes can
be persistent or even I think any distributed
capability system where the restarts of the
systems are de coupled) I argue (as before) that
they need to persist.

In all systems I believe that for safety (avoided
danger) capabilities that are issued to application
for temporary use should be revoked when the
application completes.

What about "persistence" as a category of capability
systems?  I believe I could write something up
that describes the clear non persistent case (no
long term storage, no distribution so there is no
de coupling of system restarts) for Wikipedia if
that makes sense for people.  How do people feel
about the "ports" term?

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