[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reauthentication implementation flaw due to EINTR

From: Da Zheng
Subject: Re: Reauthentication implementation flaw due to EINTR
Date: Mon, 28 Dec 2009 17:59:55 +0800
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20091204 Thunderbird/3.0


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?
> 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

Zheng Da

reply via email to

[Prev in Thread] Current Thread [Next in Thread]