[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reliability of RPC services
From: |
Marcus Brinkmann |
Subject: |
Re: Reliability of RPC services |
Date: |
Tue, 25 Apr 2006 13:16:00 +0200 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI) |
At Tue, 25 Apr 2006 06:52:05 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
>
> On Tue, 2006-04-25 at 10:38 +0200, Michal Suchanek wrote:
> > On 4/25/06, Jonathan S. Shapiro <address@hidden> wrote:
> > >
> > > Yes, so now you have a situation where client A is notified of the
> > > server's mishandling of client B. This is a security error. Coyotos will
> > > not expose this fact.
> >
> > How is client A notified of mishandling of client B? It is only
> > notified when its own capability is dropped for whatever reason. Be it
> > server is killed, just drops it, forwards it to another server that
> > fails to handle it, or overwites it with a capability received from B.
> > But A cannot tell that.
>
> You are mistaken. Assume that A and B are trying (improperly) to
> communicate by exploiting the drop notices. They *can* communicate this
> way.
>
> When reasoning about system architecture, it is rarely good to say "X
> doesn't know Y", because this assumption is often wrong. A more
> productive approach is to ask "how could X and Y exploit this to achieve
> something unexpected?"
This discussion has gone astray, probably because parties have
different models in mind (I am not sure).
In the move-only-and-send-exactly-once model, there is no
communication possible between A and B if S properly handles the reply
capabilities. If S does _not_ properly handle the reply capabilities,
all bets are off anyway. That would just be an exploit of a bug in S,
not of the system architecture.
Thanks,
MArcus
- Re: Reliability of RPC services, (continued)
- Re: Reliability of RPC services, Tom Bachmann, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/24
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/24
- Re: Reliability of RPC services, Michal Suchanek, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services,
Marcus Brinkmann <=
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Re: Reliability of RPC services, Bas Wijnen, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25
- Correctness (was: Re: Reliability of RPC services), olafBuddenhagen, 2006/04/26
- Re: Reliability of RPC services, Marcus Brinkmann, 2006/04/25
- Re: Reliability of RPC services, Michal Suchanek, 2006/04/25
- Re: Reliability of RPC services, Michal Suchanek, 2006/04/25
- Re: Reliability of RPC services, Jonathan S. Shapiro, 2006/04/25