[Spread-users] Sess_recv_client_auth: BUG! Session is alreadyauthorized (status 0x1)

Ben Laurie ben at algroup.co.uk
Wed Oct 24 07:03:59 EDT 2001


Jonathan Stanton wrote:
> 
> I believe this problem is fixed now and I have committed a fix to cvs. The
> patch that is attached to this email is essentially the same as the one
> that was reported by Dave Parker to fix the problem earlier today by
> email.
> 
> The problem this fixes is a longstanding race when connections are closed
> and opened. I do not think it was introduced in any recent version, but
> rather has been around a long time but might have showed up in different
> ways depending on the version.  This might explain some problems people
> had with clients who would create and destroy connections very quickly
> (mod_log_spread in some configurations)
> 
> Basically, when a client closes a connection to spread, the daemon has to
> send a message to all of the other daemons informing them that the client
> has quit and they should remove any state that refers to that client. This
> includes which groups that the client belonged to for example. When the
> daemon is able to order this message (possibly a short while later) it
> completes the removal of the client from its list of local sessions.
> During the period between when the client disconnects (and the daemon
> calls 'close' on the socket) and when the message about the client
> disconnection is ordered and the session state removed, the client
> exists as a 'non-operational' session. This should be fine, as the code
> makes sure a non-operational client is not able to do anything. However,
> the case of a new 'accept' call returning the same file descriptor as a
> non-operational session causes one datastructure to confuse the new and
> old sessions (it uses the fd as a key) and caused the problem Dave
> expierenced. It should have caused similar problems (with possibly
> different symptoms) in earlier versions of the code.
> 
> If anyone has any comments on this, or is able to verify that it fixes any
> connection problems they have I would appreciate hearing about it.

I'm probably missing something, but it looks to me like the patch
doesn't actually fix the problem, just makes it fatal! In order to fix
it, surely the close(mbox) must be moved from Sess_kill() to
Sess_handle_kill()? Or am I talking rubbish?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff





More information about the Spread-users mailing list