| |||||||||||||
change the default?change the default?Posted Aug 4, 2008 18:27 UTC (Mon) by pflugstad (subscriber, #224)Parent article: File descriptor handling changes in 2.6.27
I was wondering - does anyone know why not just change the default so that ALL FD's are close on exec. That would seem to be the more secure solution. I know there are places (inetd to network daemons) where passing the FD's in via exec is standard, but it would seem to be those would be the exception rather than the rule. I'm sure this was thought about, and probably tested, I'm mostly just curious about where it ran into trouble. Thanks, pete
(Log in to post comments)
change the default? Posted Aug 4, 2008 18:32 UTC (Mon) by corbet (editor, #1) [Link] 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.
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.
change the default? Posted Aug 4, 2008 19:15 UTC (Mon) by jreiser (subscriber, #11027) [Link] All shells and all pipelines would break. Having a file descriptor persist across execve is the usual way to "inherit" [share] stdin, stdout, stderr for a new application main program. Many shell scripts themselves would break, because they rely on subprocesses reading only a portion of the data (such as one line, one command, one expression) that they could read from stdin, then leaving the fd open at the correct position for the parent process (and its children) to read the next portion.
|
|||||||||||||