This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Christophe.Devriese
Recipients Christophe.Devriese
Date 2011-05-19.10:09:57
SpamBayes Score 4.09846e-10
Marked as misclassified No
Message-id <>
The specific issue this is creating is that a malicious user could use this socket in a subprocess which is started from a library (ie. I'm using a .so, which calls fork/exec).

A second failure mode is starting a daemon from withing, say, a django application. Djano opens a TCP listening socket, then starts up a daemon to provide some sort of service in the background. The daemon keeps running and inherits the socket. Now you restart the django app.

It refuses to start ! Why ? Because the socket was inherited, the listening socket isn't actually closed, and this results in the socket being stuck in CLOSE_WAIT as long as the daemon is running.

It seems to me that it is almost never the case that you'd want a TCP listening socket to be preserved across exec, and not setting this flag should thus be considered a bug for 2 reasons :

1) it results in accidental disclosure of information that shouldn't be exposed in certain cases.
2) it can result in denial of service

Solution : 

update :
  in the class TCPServer
  add the following 2 lines in __init__ after self.socket = socket( ...:
    flags = fcntl.fcntl(self.socket, fcntl.F_GETFD)
    fcntl.fcntl(self.socket, fcntl.F_SETFD, flags | fcntl.FD_CLOEXEC)
Date User Action Args
2011-05-19 10:09:58Christophe.Devriesesetrecipients: + Christophe.Devriese
2011-05-19 10:09:57Christophe.Devriesesetmessageid: <>
2011-05-19 10:09:57Christophe.Devrieselinkissue12107 messages
2011-05-19 10:09:57Christophe.Devriesecreate