[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