> from
> my current understanding of what I've read, it's not possible to have a
> *pure* capability system without also having persistence, right?
Only if you want to be able to consistently save the state of the machine. In an embedded system, for example, it's not at all necessary. There is some content related to this issue in my SOSP submission, which I will post a URL to here as soon as it's done (later tonight).
This begs a question: why do you wish to avoid persistence? Aside from the fact that checkpointing is just as efficient as conventional file I/O in the worst case and much more efficient in many cases, why do you wish to avoid it?
>I suppose it
>would be possible to have a dedicated store of all the capabilities
>belonging to every program in the system, but I'd imagine that that would
>get unmanageable very quickly.
Beware that this will lead to circular write order dependencies. From the SOSP draft:
/start quote/
When persistent objects are permitted to contain capabilities, they
take on certain characteristics of file metadata. In conventional
file systems, correct stabilization of files depends on the order of
data and metadata writes: data must be written before the metadata
that references it \cite{Ganger:Metadata}. Similarly, objects in a
capability system must be written before the capabilities that
reference those objects. Unlike a file system, however, the update
dependency graph in a capability system is unconstrained (and
potentially circular).
Plausible mechanisms to ensure a consistent system image in the store include application-managed transactions or some form of periodic consistent snapshot of the machine state. For reasons of simplicity and correctness, EROS uses a periodic checkpoint similar to the KeyKOS mechanism described by Landau \cite{KeyKOS:Checkpoint}. /end quote/
If you can find anything on it, you might want to look at SCAP, a system proposed by Paul Karger that uses both capabilities and ACLs in a reasonably clean way. I suspect that Paul could be prevailed on to send you a copy of your own.