[issue20979] Calling getdents()/readdir64() repeatedly while closing descriptors provides unexpected behaviour.

2016-09-08 Thread Марк Коренберг

Марк Коренберг added the comment:

Yes, it is still relevant. For example for closing fds after fork().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20979] Calling getdents()/readdir64() repeatedly while closing descriptors provides unexpected behaviour.

2016-09-08 Thread Christian Heimes

Christian Heimes added the comment:

Is this still relevant with O_CLOEXEC?

--
nosy: +christian.heimes
versions: +Python 3.6, Python 3.7 -Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20979] Calling getdents()/readdir64() repeatedly while closing descriptors provides unexpected behaviour.

2014-03-19 Thread Gregory P. Smith

Gregory P. Smith added the comment:

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.

--
nosy: +gregory.p.smith -gps
versions: +Python 3.3, Python 3.4, Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20979] Calling getdents()/readdir64() repeatedly while closing descriptors provides unexpected behaviour.

2014-03-19 Thread Марк Коренберг

New submission from Марк Коренберг:

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//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...

--
components: Library (Lib)
messages: 214100
nosy: mmarkk
priority: normal
severity: normal
status: open
title: Calling getdents()/readdir64() repeatedly while closing descriptors 
provides unexpected behaviour.
type: security

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue20979] Calling getdents()/readdir64() repeatedly while closing descriptors provides unexpected behaviour.

2014-03-19 Thread R. David Murray

Changes by R. David Murray :


--
nosy: +gps

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com