4 ms·
The solution I have done in my software is to close all unneeded file descriptors right after fork() in the child [1]. It can be argued that this is not the be
by ambrop7 14y ago
The solution I have done in my software is to close all unneeded file descriptors right after fork() in the child [1].
It can be argued that this is not the best solution because every place where fork() is called needs to be patched, and this could be in libraries. But the same applies to O_CLOEXEC flags; every place where file descriptors are created needs to be patched. Further, there are probably many more places where fd's are created than where fork() is called.
So if you want to be super careful library, you should do both. Yes, I know the article advises against fork() from libraries. But sometimes you really need it. It's not bad per-se, just bad when done in *nix because of the broken design of OS interfaces.
[1] http://code.google.com/p/badvpn/source/browse/trunk/system/BProcess.c#241 http://code.google.com/p/badvpn/source/browse/trunk/system/B...
- alexlarsson 14y agoYeah, and then some other thread opens a file descriptor while your loop is busy closing the last few file descriptors... CLOEXEC approaches are the only race free solutions.
- premchai21 14y agofork() only leaves the one thread running in the child, and at that point the fd tables are no longer shared, so trying to detect and close unwanted descriptors in the child after fork is not racy by itself as a way of mitigating the possibility of uncontrollable non-CLOEXEC opens elsewhere in the process (though this doesn't preclude it being a bad idea for other reasons).
- alexlarsson 14y agotrue, sorry.