[issue8052] subprocess close_fds behavior should only close open fds

Ferringb report at bugs.python.org
Sun Jan 15 11:17:26 CET 2012


Ferringb <ferringb at gmail.com> added the comment:

In #13788, I've uploaded a patch modifying closerange along the same lines as this discussion; someone w/ appropriate rights should set dependencies as needed.

Either way, here's a question: does anyone actually know of a unix that does procfs, and has a daft opendir implementation as described below?  Aka, are we actually worrying about something relevant, or just hypotheticals?

Strikes me any scenario where this actually would occur, we're already in hell from broken implementations- meaning we probably don't support them.  In the same angle, has anyone asked opengroup (forums, ml, etc), or moreso figured out *where* to ask for the given reasoning here?

Regardless, if we're dead set on adhering to the standards there (and using re-entrant readdir_r and friends isn't enough to make people happy), a few hacks come to mind:

1) in the child (child1), split a pipe, fork/exec (child2) an ls -l (or equivalent) of /proc/$PID/fd, feeding it back to child1 which then acts on it.
2) grab the fd list pre-fork along w/ the link count for /proc/$PID/fd; child re-stats /proc/$PID/fd, if link count is the same, the results should be able to be acted upon.  I'm *reasonably* sure there is a retarded FS or two out there that doesn't set link count for a directory correctly, but I've never heard of it for a procfs.  Regardless, should be detectable- nlinks would be 0.  If it is, and len(fds) != 0, then you know you can't trust the results and have to fallback to brute force close the range.  Additionally, we ought to be able to test for this... so... score.

Addressing: "signal handlers can open files".  Yes, they can, and our current implementation doesn't handle that case /anyways/, so it's orthogonal to speeding up closerange.

Finally, doing some codesearching, here's the rough list of heavy hitters spotted using this:
*) java (as mentioned)
*) chrome's seccomp sandbox uses it
*) glibc's nscd uses it (pretty strong indication this is safe in that case to say the least)
*) gdm
*) pulseaudio (limited to linux)
*) opensolaris actually does this, although from reading the code it sounds as if there is an issue w/ vfork- thus they use getdents directly.  Look for spawn_closefrom for details.

So.. seems a bit linuxy.  Could possibly enable it just there (whitelist).

----------
nosy: +ferringb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8052>
_______________________________________


More information about the Python-bugs-list mailing list