Ah..another possible problem with your solution...or alternatively with my understanding of the socket interface. What happens if the remote program submits the data, stunnel unloads the socket, and only then does the remote program close the socket? Will the s_poll_wait be triggered on the HUP alone (I guess yes)? If not, then stunnel will hang until something submits more data. But if triggered only on the HUP, the lines checking for internal failures will see an exit with no read or write data waiting, and take the longjmp() after "s_poll_wait returned %d, but no descriptor is ready". In my suggested version it did an additional check for sock_rd_hup to cope with just this scenario.
-----Original Message----- From: Graham Nayler (work) Sent: Monday, September 22, 2014 12:54 PM To: stunnel-users@stunnel.org Subject: Re: [stunnel-users] Premature socket closure - race condition bug?
Since submitting my original patch, I've realised there is a possible scenario that both my solution, and I think yours as well, still fails on: we're assuming that once the readsocket call has returned, there's nothing left in the socket buffer. Is this not dependent on the size of the data submitted by the remote program, the capacity of the socket buffer itself, and the space remaining in c->sock_buf after c->sock_ptr? I.e. there could still be data in the socket if the buffered data were longer than that returned by readsocket? Should stunnel not repoll/check the socket to ensure that POLLIN is not set before taking any action on POLLUP? Maybe s_poll_hup() should only be allowed to return POLLIN if POLLHUP is not set?
Graham
-----Original Message----- From: Graham Nayler (work) Sent: Monday, September 22, 2014 12:13 PM To: stunnel-users@stunnel.org Subject: Re: [stunnel-users] Premature socket closure - race condition bug?
Compiled and installed on the Linux Mint server and looking fine so far using my test example. If nothing shows up in the next few hours of normal running it should be fine.
It's of lower priority, but I'd like to update the client machines as well when the release goes official. This may be better in a separate thread, or already exist in an FAQ I've not found, but as I have about 50 (currently, eventually >80) sites to update (mostly Windows 7, some XPSP3), is there a way for the Windows install to be run unattended? Failing that, is there a list, or way to generate a list, of updated binaries + reg/config entries so I can make myself an unattended install/upgrade? Most sites are currently on 5.01, but some are still on 4.56.
-----Original Message----- From: Michal Trojnara Sent: Monday, September 22, 2014 11:00 AM To: stunnel-users@stunnel.org Subject: Re: [stunnel-users] Premature socket closure - race condition bug?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Graham Nayler wrote:
In the failure scenario though, the returned status was (POLLIN|POLLHUP).
Great work. I indeed forgot that the POLLHUP condition may be set while some buffered data is still available.
Could you try: https://www.stunnel.org/downloads/beta/stunnel-5.05b1.tar.gz ?
Mike
_______________________________________________ stunnel-users mailing list stunnel-users@stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
_______________________________________________ stunnel-users mailing list stunnel-users@stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
_______________________________________________ stunnel-users mailing list stunnel-users@stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users