[cap-talk] MinorFS Philosophy

Karp, Alan H alan.karp at hp.com
Sun Jul 27 23:21:37 CDT 2008

Sorry for the delay in responding.  I lost your note in a pile of unread email.

Rob Meijer wrote:
> 1) As a location where, if someone was to write a 'persistent' ocap
>    language, the process 'image' could be stored in a location only
>    accessible to the process that is to be the new incarnation of the
>    persistent process.
> 2) A location where a program written in a language with serialization
>    support can put serialized parts of itself as a way to simulate 1.
> 3) A private location for processes to store 'private' file system data
>    (dirs and files).
> 4) Delegation of (decomposed,attenuated etc) access to 3.
> 5) Making the receiving end of 4 persistent (composition).
So, the answer is, it depends, which explains my confusion.  I had been assuming your description of the original scenario included the mechanism.  The thing missing was the step needed to preserve access across invocations in the absence of persistence.

Now I have more questions.  Except for #1, doesn't the right to access the file after restarting the program resides in the user's context?  Doesn't that lose the advantage of not having all the user's permissions in a single context?  With #1, how do you control that this user, and only this user, can start the incarnation of the new process without putting some permission in the user's context?

Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029

More information about the cap-talk mailing list