New submission from Christophe Devriese <christophe.devri...@gmail.com>:
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 SocketServer.py :
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)
----------
messages: 136273
nosy: Christophe.Devriese
priority: normal
severity: normal
status: open
title: TCP listening sockets created without FD_CLOEXEC flag
type: security
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12107>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
