Re: cap exchange race with map/unmap

[Marcus Brinkmann]

At Wed, 19 Oct 2005 14:21:23 +0200,
Bas Wijnen <address@hidden> wrote:
> My intuition says that in most cases we don't care if the copy is revocable or
> not.

My intuition says your intuition is wrong.  For the sender it _always_
matters, and for the receiver it can matter, too: On the sender side,
if you are happy with a revocable copy, you probably are happy with a
real copy as well.  But that is the only "I don't care" situation I
see.

> I note that the capability server as a library approach isn't being discussed
> at the moment.  Is there something wrong with it?

Yes.  First of all, it fundamentally requires that the individual
clients and copy operations are disclosed to the server.  This may be
a violation of your security policy.

It can require too much trust when receiving a copy of a capability:
The receiver must trust the server (by making a blocking RPC to it)
even for just accepting the copy.  This may be a problem in your
system architecture design.  (I am not sure it is a problem in our
hurd-on-l4 design.  It depends on if a server actually makes a call on
an auth, container, etc capability, or if those are only used as
authentication tokens).

Furthermore, the session management required (in every server!) is
complex and a performance or resource burden.

Last but not least: It replicates every single argument against the
global cap server in each individual server.  If the cap server is
indeed problematic, as Jonathan says, (by introducing DoR attacks),
you have just multiplied the number of problems in the system by the
number of servers you run.

Thanks,
Marcus