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: Calling getdents()/readdir64() repeatedly while closing descriptors provides unexpected behaviour.
Type: security Stage:
Components: Library (Lib) Versions: Python 3.7, Python 3.6, Python 3.4, Python 3.5
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: christian.heimes, gregory.p.smith, socketpair
Priority: normal Keywords:

Created on 2014-03-19 14:53 by socketpair, last changed 2022-04-11 14:58 by admin.

Messages (4)
msg214100 - (view) Author: Марк Коренберг (socketpair) * Date: 2014-03-19 14:53
1. Please see last comments/patches for issue8052
2. Not closing some descriptos is security breach (PEP-0446 describes that)


=================
Calling getdents()/readdir64() repeatedly while closing descriptors provides unexpected behaviour. Reading directory while it modified is not safe by default. For example: http://en.it-usenet.org/thread/18514/15719/. 

So, we should re-open directory if we received full array of structures. I don't know if just lseek(dirfd, 0) sufficies.

Please reopen bug, as Linux behaviour of stable reading /proc/<pid>/fd may be broken in future without any error at python side (!) (typically, second call returns empty list if dir was modified)

=================

Also, please check exit code of getdents() instead of just ignoring error and NOT closing file descriptors.
=================

P.S. Please set affected python versions...
msg214143 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2014-03-19 23:09
A Python test that reproduces this would be nice to have though I realize it isn't something necessarily useful to run as part of a unittest suite given this one would rely on OS kernel implementation details and chances of race conditions occurring.

Regardless I agree with the general comments.  This code could be improved with better error handling given the poor APIs for getting a list of open file descriptors that we have to work with.

It should be much less of an issue in 3.4 and later due to the O_CLOEXEC default via http://legacy.python.org/dev/peps/pep-0446/ but the posixsubprocess code should be updated to handle the errors better there regardless.
msg275220 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-09-08 23:53
Is this still relevant with O_CLOEXEC?
msg275256 - (view) Author: Марк Коренберг (socketpair) * Date: 2016-09-09 05:00
Yes, it is still relevant. For example for closing fds after fork().
History
Date User Action Args
2022-04-11 14:58:00adminsetgithub: 65178
2016-09-09 05:00:03socketpairsetmessages: + msg275256
2016-09-08 23:53:53christian.heimessetnosy: + christian.heimes

messages: + msg275220
versions: + Python 3.6, Python 3.7, - Python 3.3
2014-03-19 23:09:08gregory.p.smithsetnosy: + gregory.p.smith, - gps
messages: + msg214143
versions: + Python 3.3, Python 3.4, Python 3.5
2014-03-19 14:57:29r.david.murraysetnosy: + gps
2014-03-19 14:53:46socketpaircreate