[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cap exchange race with map/unmap
From: |
Bas Wijnen |
Subject: |
Re: cap exchange race with map/unmap |
Date: |
Wed, 19 Oct 2005 16:03:13 +0200 |
User-agent: |
Mutt/1.5.11 |
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
- Re: cap exchange race with map/unmap, (continued)
- Re: cap exchange race with map/unmap, Espen Skoglund, 2005/10/18
- Re: cap exchange race with map/unmap, Jonathan S. Shapiro, 2005/10/18
- Re: cap exchange race with map/unmap, Neal H. Walfield, 2005/10/19
- Re: cap exchange race with map/unmap, Jonathan S. Shapiro, 2005/10/19
- Re: cap exchange race with map/unmap, Neal H. Walfield, 2005/10/19
- Re: cap exchange race with map/unmap, Marcus Brinkmann, 2005/10/18
- Re: cap exchange race with map/unmap, Jonathan S. Shapiro, 2005/10/18
- Re: cap exchange race with map/unmap, Ludovic Courtès, 2005/10/19
- Re: cap exchange race with map/unmap, Bas Wijnen, 2005/10/19
- Re: cap exchange race with map/unmap, Jonathan S. Shapiro, 2005/10/19
- Re: cap exchange race with map/unmap,
Bas Wijnen <=
- Re: cap exchange race with map/unmap, Marcus Brinkmann, 2005/10/19
- Re: cap exchange race with map/unmap, Marcus Brinkmann, 2005/10/19
- Re: cap exchange race with map/unmap, Jonathan S. Shapiro, 2005/10/19
- Re: cap exchange race with map/unmap, Neal H. Walfield, 2005/10/19
- Re: cap exchange race with map/unmap, Marcus Brinkmann, 2005/10/19
- Re: cap exchange race with map/unmap, Neal H. Walfield, 2005/10/19
- Re: cap exchange race with map/unmap, Marcus Brinkmann, 2005/10/19
- Re: cap exchange race with map/unmap, Jonathan S. Shapiro, 2005/10/19
- Re: cap exchange race with map/unmap, Marcus Brinkmann, 2005/10/19
- Re: cap exchange race with map/unmap, Jonathan S. Shapiro, 2005/10/19