On Mon, 2009-03-02 at 17:07 -0600, William A. Rowe, Jr. wrote: > This entire patch set has me increasingly worried, as it has the strong > potential of destabilizing many apr apps.
The _intention_ of the patch (at least as interpreted by me) is that if the file has APR_INHERIT_SET flag turned _off_, then we also flag the fd with CLOEXEC. Otherwise, we don't. So, if someone opened a file through APR file API with an inherit flag turned off, we now guarantee that this fd will be closed even when the fork/exec was _not_ done through APR. Whether we actually implemented that correctly in the patch is another matter. More eyes welcome here. Now, if people were relying/exploiting these fds being opened across fork/exec calls that are not done via APR, then we have a security issue in the current code. This is what O_CLOEXEC is all about - no free fds for anyone, unless explicitly given. No? > Let's review what -should- happen today; > > apr_file_open_stderr(&stderr_log, p) > > should return stderr_log apr_file_t indicating the INHERIT flag set. Then; > > apr_file_dup2(stderr_log, new_file, p) > > should maintain the INHERIT flag on the newly dup2'ed stderr_log. > > Does that make sense? It does. -- Bojan
