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.

classification
Title: Windows: Make handle non inheritable by default
Type: Stage:
Components: Windows Versions: Python 3.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: sbt, tim.golden, vstinner
Priority: normal Keywords:

Created on 2014-04-29 08:59 by vstinner, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (3)
msg217501 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2014-04-29 08:59
The PEP 446 was implemented in Python 3.4. All file descriptors are now created non inheritable. The implementation was not finished on Windows, handles may be created inheritable. The Python code should be audoted for that.

For example, hCryptProv in Python/random.c is inheritable or not?
msg217593 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2014-04-30 10:00
On Windows, handles are created non-inheritable by default, but I would prefer to double check.

The tool "Handle" can be used to list all open handles of a process:
http://technet.microsoft.com/en-us/sysinternals/bb896655.aspx

To test that all handles are non-inheritable: run all Python unit tests, create a subprocesss with close_fds=False, list open handles of the child process and check that the list of not longer than a fresh Python process.
msg218365 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2014-05-12 21:23
> For example, hCryptProv in Python/random.c is inheritable or not?

This is not a standard handle. GetHandleInformation() fails with a Windows error 6 (invalid descriptor).

I listed inheritable handles with a loop on range(0, 0x1001): only handles of stdin, stdout and stderr are inheritable. The other handles are not inheritable.

I also listed handles of parent and child processes using "handle.exe" tool from Microsoft. I see that the child has less open handle, all file handles that I opened manually are not inheried, and everything looks fine.

So I think that the issue can now be closed.
History
Date User Action Args
2022-04-11 14:58:02adminsetgithub: 65583
2014-05-12 21:23:40vstinnersetstatus: open -> closed
resolution: fixed
messages: + msg218365
2014-04-30 10:00:23vstinnersetmessages: + msg217593
2014-04-29 08:59:41vstinnercreate