[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: auth handshake and rendevouz objects

From: Bram Meersman
Subject: Re: auth handshake and rendevouz objects
Date: Mon, 04 Nov 2002 15:59:28 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1

Marcus Brinkmann wrote:

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]