Re: [PATCH 2/2] Reverse authenticating ioctl-handler protocol

[olafBuddenhagen]

Hi,

On Wed, Aug 26, 2009 at 04:21:43PM +0200, Carl Fredrik Hammar wrote:

> +    * The client sends an `ioctl_handler_request' to the server,
> +      with a rendezvous port.
> +
> +    * The server sends an `ioctl_handler_acknowledge' in reply, this
> +      is needed so that the client won't wait indefinitely for
> +      `auth_server_authenticate' to return if the server does not support
> +      this protocol.
> +
> +    * The client sends an `auth_server_authenticate' with the rendezvous
> +      port and a reply port to the auth server.  (Note the reversal of
> +      the roles of client and server from the normal auth protocol.)
> +
> +    * The server sends an `auth_user_authenticate' with the rendezvous
> +      port to the auth server.
> +
> +    * The auth server matches up the requests using the rendezvous port,
> +      and returns the reply port to the server and the server's ID block
> +      to the client.
> +
> +    * The server sends a port to a file that can be opened with `dlopen'
> +      and exports an`ioctl_handler_t' typed function named
> +      `hurd_ioctl_handler'.

This last bit is the ioctl_handler_reply part I think?

I think the protocol could be simpified a lot by using a normal RPC, and
letting the server wait for the auth_user_authenticate() reply
asynchronously. (Or not wait for it at all, if auth can deal with
this...) The server is not really interested in the result of the
authentication -- there is no reason to wait for it before returning the
module file...

Also, the detailed description of the protocol should probably go into
the Hurd reference manual...

-antrik-