Re: Reauthentication implementation flaw due to EINTR

[Da Zheng]

On 09-12-28 下午6:14, Samuel Thibault wrote:
> 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.
My question was where the thread jumps to when it is interrupted by the deadname
notification. I thought the thread directly jumps to a place to return EINTR
instead of executing the code below hurd_condition_wait(). That is, the deadname
notification doesn't interrupt hurd_condition_wait(), but interrupt the whole
auth_server_authenticate RPC. My understand may be wrong. I just see the comment
in ports_interrupt_self_on_notification:
"Arrange for hurd_cancel to be called on the current thread, which should
   be an rpc on OBJECT, if PORT gets notified with the condition WHAT."
OBJECT is userauth and PORT is the rendezvous port in our case. Doesn't it mean
the RPC on userauth (namely, auth_user_authenticate) is to be canceled?
> 
> 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.
As Fredrik said and as I understand, while the server side of
auth_server_authenticate RPC is waiting for the signal from the
auth_user_authenticate, auth_server_authenticate RPC can be canceled by the
deadname notification if the client gets scheduled first and destroys the
rendezvous port and thus the auth_server_authenticate RPC returns EINTR. The
right thing to do is that before the server side of auth_user_authenticate RPC
returns, it cancels the deadname notification. In this case,
auth_server_authenticate RPC can never be interrupted by the deadname
notification any more even if the rendezvous port is destroyed before
auth_server_authenticate RPC gets its chance to run.

Zheng Da