Re: Reliability of RPC services

[Bas Wijnen]

On Sat, Apr 22, 2006 at 01:53:28PM -0400, Jonathan S. Shapiro wrote:
> On Sat, 2006-04-22 at 17:49 +0200, Pierre THIERRY wrote:
> > Scribit Pierre THIERRY dies 22/04/2006 hora 17:35:
> > > I'm not familiar at all with the use of capabilities by a program, but
> > > couldn't S drop it's capability in a way that won't trigger the send
> > > that the "invoke on delete" bit asks for?
> > 
> > I reply to myself (mea culpa, for I didn't read all the thread before
> > sending my mail): IIUC, that would enable a malicious S to let C be
> > waiting indefinitely for the answer, never getting it nor any
> > notification that no answer will ever be able to reach it (because the
> > reply capability is not owned by anyone or because the owner is
> > destroyed). Am I right?
> 
> It is not possible in principle to prevent this. Do the exercise: design
> an S that achieves this denial even if "send on overwrite" is present.

Marcus' idea was that cleanup should at least take place when S is destroyed,
even if it is malicious.  That is, when the user finds out that S is
malicious, he kills it.  At that point, it is reasonable that programs want to
abort their blocking operation.  The send-once solution Marcus wrote about
works, but appearantly it is expensive.  I think there is an other way for
this, but I may be wrong (or it may be just as expensive).  I'm replying about
this in an other message.

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