[issue21627] Concurrently closing files and iterating over the open files directory is not well specified

Steven Stewart-Gallus added the comment: Okay, I made a patch that I hoped dealt with all the criticisms and that fixed up a problem I noted myself. -- Added file: http://bugs.python.org/file35599/fixed-setcloexec.patch ___ Python tracker rep

[issue21627] Concurrently closing files and iterating over the open files directory is not well specified

Changes by Steven Stewart-Gallus sstewartgallu...@mylangara.bc.ca: Removed file: http://bugs.python.org/file35599/fixed-setcloexec.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21627

[issue21627] Concurrently closing files and iterating over the open files directory is not well specified

Changes by Steven Stewart-Gallus sstewartgallu...@mylangara.bc.ca: Added file: http://bugs.python.org/file35600/fixed-setcloexec.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21627

[issue21627] Concurrently closing files and iterating over the open files directory is not well specified

Steven Stewart-Gallus added the comment: Okay, now I'm confused. How would I conditionally compile and use the setcloexec object and header on POSIX platforms and not on Windows? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org

[issue21627] Concurrently closing files and iterating over the open files directory is not well specified

Steven Stewart-Gallus added the comment: Okay, so the Python directory seems to be where wrappers over low level or missing functionality is placed. So I guess I should make a _Py_setcloexec function in a Python/setcloexec.c and a definition in Include/setcloexec.h

[issue21627] Concurrently closing files and iterating over the open files directory is not well specified

Steven Stewart-Gallus added the comment: It occurred to me that the current patch I have is wrong and that using _Py_set_inheritable is wrong because EBADF can occur in the brute force version which in the case of _Py_set_inheritable raises an error which I am not sure is asynch signal safe

[issue21618] POpen does not close fds when fds have been inherited from a process with a higher resource limit

Steven Stewart-Gallus added the comment: Thank you for the very quick patch Gregory P. Smith. It's fair enough if you don't bother to fix the EINTR issue. One small note: +Confirm that issue21618 is fixed (mail fail under valgrind). That's a typo right? Shouldn't it be may instead

[issue21627] Concurrently closing files and iterating over the open files directory is not well specified

New submission from Steven Stewart-Gallus: Hello, I noticed some possible bad behaviour while working on Python issue 21618 (see http://bugs.python.org/issue21618). Python has the following code in _posixsubmodules.c for closing extra files before spawning a process: static void

[issue21627] Concurrently closing files and iterating over the open files directory is not well specified

Steven Stewart-Gallus added the comment: Okay, I've made a simple proof of concept patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21627

[issue21627] Concurrently closing files and iterating over the open files directory is not well specified

Steven Stewart-Gallus added the comment: Gah, I had trouble figuring out mecurial. Close files after reading open files and not concurrently This commit removes the old behaviour of closing files concurrently with reading the system's list of open files and instead closes the files after

[issue21618] POpen does not close fds when fds have been inherited from a process with a higher resource limit

Steven Stewart-Gallus added the comment: I agree that this is not a likely scenario but I can think of one mildly plausible scenario. Suppose some web server runs a Python CGI script but has a bug that leaks a file descriptor into the script. The web server sandboxes the Python CGI script

[issue21618] POpen does not close fds when fds have been inherited from a process with a higher resource limit

Steven Stewart-Gallus added the comment: I found another problem with _close_open_fd_range_safe. POSIX leaves the state of a file descriptor given to close undefined if the close fails with EINTR. I believe but haven't double checked that close should not be retried on EINTR on all of our

[issue21618] POpen does not close fds when fds have been inherited from a process with a higher resource limit

Changes by Steven Stewart-Gallus sstewartgallu...@mylangara.bc.ca: -- type: - security versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21618

[issue21618] POpen does not close fds when fds have been inherited from a process with a higher resource limit

New submission from Steven Stewart-Gallus: The sysconf(_SC_OPEN_MAX) approach to closing fds is kind of flawed. It is kind of hacky and slow (see http://bugs.python.org/issue1663329). Moreover, this approach is incorrect as fds can be inherited from previous processes that have had higher

[issue21618] POpen does not close fds when fds have been inherited from a process with a higher resource limit

Steven Stewart-Gallus added the comment: Okay here's a stub patch that address FreeBSD, NetBSD and Linux. I'm not sure how to address the other platforms. -- keywords: +patch Added file: http://bugs.python.org/file35419/python.patch ___ Python

[issue21618] POpen does not close fds when fds have been inherited from a process with a higher resource limit

Steven Stewart-Gallus added the comment: Oh right! I forgot a possible problem with my proposed patch. It is incompatible with Valgrind (see issue https://bugs.kde.org/show_bug.cgi?id=331311). Either this patch won't be applied, Valgrind compatibility is judged not essential or the Valgrind