[cap-talk] Capability-based Projects - theory vs. practice

[Mark Miller]

On 8/3/07, Jed Donnelley <capability at webstart.com> wrote:
> I can understand how file content that might be modified by
> executing E programs will survive.  What I don't understand
> is how that effects any sort of permanent sharing between
> users - e.g. on a Unix system for example.  When the system
> restarts all process state is lost.

A persistent E vat checkpoints some of its state to its checkpoint
file on the file system. Such a checkpoint file records the persistent
capabilities that its vat holds to objects in other vats as
cap-as-data URIs. So, inter-vat, E provides only cap-as-data security,
both for ephemeral caps and for persistent caps.

>  While there may be
> some changed file contents for some users, how does that
> effect sharing?

Persistent sharing is affected when a vat replaces its old checkpoint
with a new one.

>  Does E do something with Unix's ACLs that
> somehow effects permanent sharing between users?

No, we never manipulate the platform's base permission system at all.


> Skip this if you already understand my question, but let
> me describe in a bit more detail in case not.  Unix user
> Jed and Unix user MarkM initially have no shared
> file content on Unix.  However they can both communicate
> on the network which allows them to communicate through
> vats.  Somehow (I don't think these details matter, but
> perhaps they do) user Jed and user MarkM run some E
> programs that effect some sharing of capabilities through
> networking between their vats.  For example, let's say
> that user Jed sends a RW capability to a file to user
> MarkM.
>
> Now the Unix system reboots.  How does user MarkM
> exercise his RW access to user Jed's file?  Perhaps
> both user Jed and user MarkM have to initialize
> E 'demon's that pick up the changed file state and
> permit communication from user MarkM to modify user
> Jed's file - e.g. through the vat mechanism on the
> network?

Yes, exactly. You got it!


> I hope my question is clear.  There's something
> fundamental here that I think I'm missing.

Looks to me like you figured out the fundamentals I hadn't thought to explain.

-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM