[Python-Dev] 2.4 asyncore headache (original) (raw)

Tim Peters tim.peters at gmail.com
Sat Aug 14 03:22:32 CEST 2004

[Nick Coghlan]

Is testsocketserver currently passing for you?

Yes, on WinXP, and regardless of whether "currently" means before or after Andrew reverted the change (& all the ZODB 3.3 tests pass under current CVS Python on Windows after the reversion).

A couple of days ago I ran the test suite with -unetwork, and that test failed, but I haven't got around to looking into it yet. Could this be related?

Which OS? asyncore isn't involved in that test, so the patch could not have affected it. SocketServer.py has its own, separate code using SO_REUSEADDR in some cases.

test_socketserver.pickport() never reuses a port number anyway. However, it may pick a port number that happens to be already in use outside the test, so that could fail. The port numbers it picks depend on the process id, so a "picked a port # already in use" failure mode may disappear on the next run.

[rambling discussion of what I found out about this so far follows]

Anyway, after some hunting, the difference between Windows and Unix SOREUSEADDR, is that on Unix, this only allows local address reuse when the existing socket is in a TIMEWAIT state. On Windows, it allows local address reuse anytime. See http://hea-www.harvard.edu/~fine/Tech/addrinuse.html. Look for the phrase 'security stigma', then read the bit starting with 'On some operating systems. . .'

It also says:

This is only a problem on multi-user machines that don't have restricted
logins, it is NOT a vulnerability from outside the machine. And it is easily
avoided by binding your server to the machine's address.

If you're running a server on an open Windows machine, worrying about details of socket reuse may not be the best use of your security time .

The issue is that if we don't set SOREUSEADDR on Windows, then you get into problems with getting EADDRINUSE when you shutdown and restart a TCP/IP server on the same local address (generally if the socket has gone into TIMEWAIT while shutting down).

That's why ZEO calls asyncore's set_reuse_addr(), so that it can shutdown/restart rapidly. This has worked fine for years on Windows.

Looking at MSDN, SOEXCLUSIVEADDRUSE is a way to say 'make my socket behave like a UNIX socket without SOREUSEADDR specified'. That is, with no options specified, a Windows socket is vulnerable to having another process come along, specify SOREUSEADDR for their socket options, and succeed in reusing the same local port.

(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/usingsoexclusiveaddruse.asp)

asyncore shouldn't use this.

What I can't find is a way to get Unix-like SOREUSEADDR behaviour on Windows.

Well, the more I learn about this one, the less I care about it. ZEO can live with Unix-like SO_REUSEADDR behavior too -- I think. I have to wonder, because reports of "connection refused" kinds of ZEO test failures have always been much more common on Linux boxes.

More information about the Python-Dev mailing list