LWN.net Logo

File descriptor handling changes in 2.6.27

File descriptor handling changes in 2.6.27

Posted Aug 5, 2008 13:33 UTC (Tue) by mheily (guest, #27123)
In reply to: File descriptor handling changes in 2.6.27 by bojan
Parent article: File descriptor handling changes in 2.6.27

> This is what I'm trying to say: if this fork() and execve() is not your code, but something
from a proprietary plugin for which you have no source, you cannot control it at all. 

True. But consider the converse of your argument: what if the proprietary plugin has called
open() on several files, but failed to set the O_CLOEXEC flag? When you then go to call fork()
and execve() in your own code, you might accidentally leak file descriptors to the child
without even knowing it.

That is why it would be good to also have a closefrom() system call. This function ensures
that the only descriptors inherited are stdout, stdin, and stderr.


(Log in to post comments)

File descriptor handling changes in 2.6.27

Posted Aug 5, 2008 22:29 UTC (Tue) by bojan (subscriber, #14302) [Link]

Yeah, different problems require different solutions.

File descriptor handling changes in 2.6.27

Posted Aug 9, 2008 23:12 UTC (Sat) by jlokier (guest, #52227) [Link]

So true.  But as noted, you can read /proc/self/fd/ on Linux to achieve the same thing -
writing your own closefrom().  Or if you're prepared to just call close() a lot, up to the
maximum number of open files in this process, you can do that too.

File descriptor handling changes in 2.6.27

Posted Mar 2, 2011 19:22 UTC (Wed) by gps (subscriber, #45638) [Link]

But you can't do that... When a program has fork()ed but has not yet called exec() the only system calls it can make are async-signal-safe system calls. opendir() and readdir() are not on that list. Linux is left with no way to close all open file descriptors other than calling close() on all _possible_ file descriptors (a real slow pain in the ass when your max fd limit is in the millions) in between the fork() and exec() to deal with ones that may not have been opened with CLOEXEC.

See
http://www.opengroup.org/onlinepubs/009695399/functions/f... and http://www.opengroup.org/onlinepubs/009695399/functions/x...

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds