Re: auth handshake and rendevouz objects

[Bram Meersman]

Marcus Brinkmann wrote:

> > Hi,
> > I have read the discusion, and I don't think I like either of the protocols.
> >
> > In both cases proxies are required to rpc to {Auth | Client} in order to 
> > pass on the rendezvous handle ,
> > so proxies will have to trust {Auth | Client}( if a thread performing an 
> > rpc sets a 0 receive timeout, the rpc will fail ).
> >
> > In Hurd/mach proxies just pass on port rights, only Client and Server 
> > have to communicate with Auth.
> > Client and Server might even be the only tasks who trust Auth.
> >    
>
> I don't understand what you are saying.  Maybe this is because I don't know
> what you mean by "proxy".  Passing a handle in HUrd on L4 is a complex
> operation, it requires the recipient and the sender of the handle to contact
> the server that provides the object which we pass the handle for.  But that
> is ok, we make all the right guarantees so that it will have similar
> semantics to passing a send right in Mach.  Except that in Mach we have one
> central object server shared by all object providing servers, while in Hurd
> on L4 we have one object server per object providing server process.
Can I find an explanation about handle passing in Hurd/L4 somewhere on 
the web ?

> I don't see any other process involved in the protocol we discussed except
> the user, the server, and auth.
>
> Beside explaining what you don't like about this, I would also like to know
> if you have any other suggestions?
>  
Following scenario is possible in Hurd/Mach :
There are 4 processes involved in this scenario: Client, Server, Auth 
(an authentication server only trusted by Client and Server), and Proxy 
( a proxy server ).

(1) Client wants to open a file
(2) Client creates a pair of rendezvous ports
(3) Client sends one rendezvous port to Auth (calls 
auth_user_authenticate )and another to Proxy
(4) Proxy sends the port it received from Client to Server
(5) Server sends the port it received from Proxy to Auth, together with 
a server port (calls auth_server_authenticate)
(6) Auth matches the two rendezvous ports, sends server port to Client 
and Client_UID to Server

Proxy just passes around port rights, he doesn't know the identity of 
Client. He also has to trust neither Client or Server.
Proxy doesn't even need an auth port.

imho such a proxy server should be possible in Hurd/L4 too.

However, both of the proposed protocols would require Proxy to RPC to 
either Client or Auth (for sending the object handles).
Proxy would block waiting for Client or Auth, both cannot be trusted.

I don't like the proxy server blocking on the client.
I don't like the proxy server blocking on the auth server, since the 
auth sever can be chosen by the client.

I 've come up with a protocol which allows the scenario I described (I 
think).
I 'll post it later on.

   Bram.