Re: Reauthentication implementation flaw due to EINTR

[Samuel Thibault]

Da Zheng, le Mon 28 Dec 2009 17:59:55 +0800, a écrit :
> On 09-12-28 上午3:56, Carl Fredrik Hammar wrote:
> > 
> > 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.
> So the registered deadname notification can cancel the RPC (i.e,
> auth_server_authenticate RPC is this case)? and the thread will somehow jump 
> to
> some place to return EINTR and doesn't execute hurd_condition_wait() and the
> code below it?

It does, but that's not a problem in the case of auth now that I have
patched it.

Where this is a problem is in ext2fs which was calling
auth_server_authenticate(). That function gets an EINTR from mach_msg
and returns it.

> > 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.
> Is it OK to extend libports to have some function to cancel the notification
> request?

I actually believe that's already the case: libports remembers the
notification request and disables it on RPC termination, which should be
enough for itself.  What I still don't understand is the link between
auth requesting a notification and ext2fs also getting the EINTR.

Samuel