Re: Reauthentication implementation flaw due to EINTR

[Carl Fredrik Hammar]

On Sat, Dec 26, 2009 at 06:56:48PM +0100, Samuel Thibault wrote:
> Carl Fredrik Hammar, le Sat 26 Dec 2009 18:47:51 +0100, a écrit :
> > Is it the code below from S_auth_server_authenticate the problem?
> > 
> >   /* Store the new port and wait for the user RPC to wake us up.  */
> >   s.passthrough = newport;
> >   condition_init (&s.wakeup);
> >   ports_interrupt_self_on_port_death (serverauth, rendezvous);
> >   if (hurd_condition_wait (&s.wakeup, &pending_lock))
> >     /* We were interrupted; remove our record.  */
> >     {
> >       hurd_ihash_locp_remove (&pending_servers, s.locp);
> >       err = EINTR;
> >     }
> > 
> > That is, does hurd_condition_wait get canceled even though the condition
> > was signaled before it was canceled?
> 
> There is this issue as well, which I have fixed already in commit
> 041baa80 (and indeed seen cases where it helped), but that's not enough,
> because not only auth gets EINTR here and can fix things, but ext2fs
> also gets an EINTR but can't able to restart the call in iohelp_reauth
> since the rendez-vous port is dead and thus gets EINVAL.

Why does this happen?  I can't find any setup code for getting interrupts
like in auth.  Is it perhaps a feature of MIG or Mach?  Can't it be
turned off?

Does the translator get interrupted even if the rendezvous port dies
between the time auth sends its reply, and the translator receives it?
Your fix wouldn't handle such a case, I think.

If this is a problem, I think the only way to fix it is at the protocol
level.  Say if io_reauthenticate actually waits for a reply, which would
signal that the translator is done using the rendezvous.  That is:

Client:           Server:             Auth:
auth_user_auth ---------------------> ...
io_reauth ------> auth_server_auth -> ...
... <------------ io_reauth_reply  <- auth_server_auth_reply
... <-------------------------------- auth_user_auth_reply

This would be a more robust protocol IMHO.  It could even handle the case
where client and server uses different auth servers for some reason (which
is actually what made me think of it originally).  The implementation
of auth could also be simplified since it can assume that the client
contacts it before the server.  Of course, changing the auth protocol
would lead to painful upgrades for users, so it might not be worth it.

Regards,
  Fredrik