Re: cap exchange race with map/unmap

[Bas Wijnen]

On Wed, Oct 19, 2005 at 09:38:44AM -0400, Jonathan S. Shapiro wrote:
> Bas:
> 
> In order to make sure that your mental picture of this protocol is
> precise, could you please resend it using my expanded notation, where
> every transfer is explicitly state?

Sure.  Given that the only primitive operation is REVOCABLE COPY, all arrows
are REVOCABLE COPYs.

First client A requests a capability from server S via capability server C.
The result is

   rev copy      rev copy
S ----------> C ----------> A

Then A copies the capability to client B, using the capability server to do
it, resulting in:

   rev copy      rev copy
S ----------> C ----------> A
               \
                `---------> B
                 rev copy

> > I note that the capability server as a library approach isn't being
> > discussed at the moment.  Is there something wrong with it?
> 
> As a transitional implementation for application bringup it's fine, but
> I suspect that it is insecure. Can you describe it under a new subject
> line, or point me at an existing description in the email archives?

I could, but Marcus just convinced me that there's not really a point in
discussing it.  It has all the problems of a capability server process, and
probably some more.  If it should be discussed at all, then that should be
after we've reached some conclusions about the capability server as a process.
If you want some description anyway, let me know.  I'm not sure if anything is
written out, I learned most about it by reading the source.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature