New submission from Jack O'Connor: The Windows implementation of Popen calls _make_inheritable(), which creates inheritable copies of Popen's file descriptors. If two Popen calls happen at the same time on different threads, these descriptors can leak to both child processes. Here's a demonstration of a deadlock caused by this bug:
https://gist.github.com/oconnor663/b1d39d58b232fc627d84 Victor Stinner also wrote up a summary of the security issues associated with leaking file descriptors in PEP 0446. A workaround for this issue is to protect all Popen calls with a lock. Calls to wait() and communicate() don't need to be protected, so you can release the lock before you make those blocking calls. I don't see a way to safely use run() or the other convenience functions, if you're using pipes and multiple threads. Unfortunately close_fds=True is not allowed on Windows when any of stdin/stdout/stderr are set, which is going the be the case here. Would it be feasible for Popen.__init__() to automatically protect the inheritable copies it creates, with a lock around that section? We already have the _waitpid_lock for POSIX, so it seems like thread safety is a goal. ---------- components: Library (Lib) messages: 254168 nosy: oconnor663 priority: normal severity: normal status: open title: subprocess.Popen creates inheritable file descriptors on Windows, can leak to other child processes type: security versions: Python 3.5 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25565> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
