← Back to context Comment by stabbles 1 day ago Isn't that covered by O_CLOEXEC? 4 comments stabbles Reply sanderjd 1 day ago I think it is error prone to need to iterate file descriptors and set this in order to inherit nothing. Excluding by default would make sense IMO. anarazel 1 day ago There's a bunch of nastiness around that too. If you have e.g. library state that assumes the fd still works you can get her very confusing bugs once another file is opened into that fd number... JdeBP 1 day ago You may be mixing up fork and exec. Library data state isn't retained over execve(), and O_CLOEXEC does not take effect at fork(). anarazel 1 day ago Indeed. Not enough coffee, apparently.
sanderjd 1 day ago I think it is error prone to need to iterate file descriptors and set this in order to inherit nothing. Excluding by default would make sense IMO.
anarazel 1 day ago There's a bunch of nastiness around that too. If you have e.g. library state that assumes the fd still works you can get her very confusing bugs once another file is opened into that fd number... JdeBP 1 day ago You may be mixing up fork and exec. Library data state isn't retained over execve(), and O_CLOEXEC does not take effect at fork(). anarazel 1 day ago Indeed. Not enough coffee, apparently.
JdeBP 1 day ago You may be mixing up fork and exec. Library data state isn't retained over execve(), and O_CLOEXEC does not take effect at fork(). anarazel 1 day ago Indeed. Not enough coffee, apparently.
I think it is error prone to need to iterate file descriptors and set this in order to inherit nothing. Excluding by default would make sense IMO.
There's a bunch of nastiness around that too. If you have e.g. library state that assumes the fd still works you can get her very confusing bugs once another file is opened into that fd number...
You may be mixing up fork and exec. Library data state isn't retained over execve(), and O_CLOEXEC does not take effect at fork().
Indeed. Not enough coffee, apparently.