Ghosts of Unix past, part 2: Conflated designs

Posted Nov 8, 2010 21:13 UTC (Mon) by Yorick (guest, #19241)
In reply to: Ghosts of Unix past, part 2: Conflated designs by dd9jn
Parent article: Ghosts of Unix past, part 2: Conflated designs

Reading /proc/self/fd/ and closing only those found there is a bit better, but not quite as portable and still a lot slower than something like BSD closefrom(), which surely would be handy.
But it would still be inferior to having CLOEXEC by default (or passing a list of descriptors to preserve to exec). It is way too easy to leak descriptors by accident or because of careless code in a library.

Ghosts of Unix past, part 2: Conflated designs

Posted Nov 11, 2010 1:10 UTC (Thu) by jonabbey (guest, #2736) [Link] (3 responses)

Reading from /proc/self/fd and closing descriptors based on that is still subject to race conditions in threaded programs.

Ghosts of Unix past, part 2: Conflated designs

Posted Nov 11, 2010 2:38 UTC (Thu) by foom (subscriber, #14868) [Link]

Nope, it's not, because you do the closing of fds after forking (but before exec). You are guaranteed that there will be no other threads running at that point.

Ghosts of Unix past, part 2: Conflated designs

Posted Nov 11, 2010 3:30 UTC (Thu) by quotemstr (subscriber, #45331) [Link]

After fork(), a program has one thread.

Ghosts of Unix past, part 2: Conflated designs

Posted Nov 17, 2010 0:23 UTC (Wed) by mhelsley (guest, #11324) [Link]

And if your process links with libraries that internally use fds then you could easily trample the "internal" workings of those libraries by closing the fds. So a naive process can't assume it knows how to handle each fd in /proc/self/fd* without blurring the lines between library and application.

Ghosts of Unix past, part 2: Conflated designs

Posted Nov 11, 2010 11:28 UTC (Thu) by dd9jn (✭ supporter ✭, #4459) [Link]

Thanks for the pointer to closefrom - not exactly what I want but helpful. Time for a new configure test. And, yes, /proc/foo is not portable enough.