[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
http://www.hpl.hp.com/personal/Alan_Karp
talk
More information about the cap-talk
mailing list