At Wed, 19 Oct 2005 15:37:17 +0200, Marcus Brinkmann wrote: > > At Wed, 19 Oct 2005 14:21:23 +0200, > Bas Wijnen <[EMAIL PROTECTED]> wrote: > > 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).
I think this is the killer argument for the cap server as library design: in order for a client, A, to pass a capability to a second client B, B must make a blocking call to the server implementing the object named by the capability. This is not a problem if B will invoke the capability eventually anyways as is the general case, e.g. when using a file object. However, capabilities are not always used like this: sometimes they are only passed as arguments. Imagine that a task (A) uses the system auth server (AUTH), that a second task (B) uses a proxy auth server (PROX) which in turn interfaces with AUTH and that A wants to authenticate itself to B. According to the current protocols (i.e. as inherited from the Hurd on Mach), A invokes auth_user_authenticate on a capability naming AUTH. AUTH returns a capability to A which it needs to pass to B. According to the protocol, B would then invoke auth_server_authenticate on a capability naming its auth server passing the capability as an argument (as well as the permitted users). The problem is that in order for B to accept the capability from A, it must make a blocking call to AUTH, however, B knows nothing directly about AUTH: it only knows about it via PROX. Since we know the context, B could ask its auth server, i.e. PROX, if AUTH is trusted, before accepting the capability. As you can see, the protocol gets increasingly complex and performance is problematic. Thanks, Neal _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
