Re: Reauthentication implementation flaw due to EINTR

[Carl Fredrik Hammar]

On Sun, Dec 27, 2009 at 08:56:21PM +0100, Carl Fredrik Hammar wrote:
> On Sat, Dec 26, 2009 at 09:12:08PM +0100, Samuel Thibault wrote:
> > I've checked again the result
> > 
> > Carl Fredrik Hammar, le Sat 26 Dec 2009 19:58:12 +0100, a écrit :
> > > > 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 don't know, but I know for sure that auth_server_authenticate returns
> > EINTR in ext2fs (and next call returns EINVAL), even if auth never
> > returned EINTR.
> 
> OK, I think I have a vague picture of what is going on:
> ports_interrupt_self_on_port_death
> ports_interrupt_self_on_notification
> ports_interrupt_rpc_on_notification,
> which requests notification (to the same port as
> auth_server_authenticate).
> 
> When rendezvous port dies we get the notification:
> ports_notify_server
> ports_do_mach_notify_dead_name
> ports_dead_name
> ports_interrupt_notified_rpcs
> hurd_thread_cancel (in glibc)
> _hurdsig_abort_rpcs,
> which does some funky stuff that seems to hijack any pending RPCs
> to make them return EINTR.
> 
> If the notification request is canceled before auth_user_authenticate
> returns there should be no problem.  I don't know how to do that, as
> libports doesn't seem to have a function for it.  The primitive function
> would be mach_port_request_notification with a null port, but I assume
> there is other stuff to clean up.
> 
> Alternatively, the notification can be handled separately by the auth
> server, perhaps by overriding libports's notify server.

Oh sorry, I did not think through how this affects your original solution.
AFAICT, after auth_server_authenticate_reply returns _hurdsig_abort_rpcs
can not hijack it, so your solution should work.  But all this is a bit
over my head so I can't tell for sure.  Canceling the notification would
be safer in this respect, if you can figure out how to do it.

Regards,
  Fredrik