[Top][All Lists]

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

Re: Reauthentication implementation flaw due to EINTR

From: Carl Fredrik Hammar
Subject: Re: Reauthentication implementation flaw due to EINTR
Date: Sun, 27 Dec 2009 20:56:21 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

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:
which requests notification (to the same port as

When rendezvous port dies we get the notification:
hurd_thread_cancel (in glibc)
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.


reply via email to

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