LWN.net Logo

change the default?

change the default?

Posted Aug 4, 2008 18:32 UTC (Mon) by corbet (editor, #1)
In reply to: change the default? by pflugstad
Parent article: File descriptor handling changes in 2.6.27

Changing the default behavior would be an ABI change and a violation of the various applicable standards as well. Some applications - quite a few of them, actually - would certainly break.


(Log in to post comments)

change the default?

Posted Aug 18, 2008 7:25 UTC (Mon) by kasperd (guest, #11842) [Link]

Yes, changing the API/ABI is not a good idea. Extending it is better. But adding flags to
every system call creating file descriptors doesn't really solve the problem. You still have
to have control over all the code that opens file descriptors. And since these new calls are
presumably not standard, any library intended to be portable will have the problems.

I absolutely agree, that close on exec should have been the default to begin with. But
changing it would break standards and compatibility. Instead I think the easiest fix would be
to introduce a new rctl that sets the default value of the close on exec flag.

Any program that does not rely on the default value of the close on exec flags can call this
prctl to secure itself against these race conditions. It does not need changes to any
libraries opening file descriptors and neither to any libraries starting child processes.

Probably it would be a good idea to make dup2 create file descriptors without close on exec if
it replace an existing file descriptor that did not have it, as well as whenever it creates a
new file descriptor with a number less than three. Otherwise too much code would require
changes.

Of course the value of this prctl would have to be reset on any successful execve call.

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