apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: svn propchange: r747990 - svn:log
Date Mon, 02 Mar 2009 23:48:13 GMT
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


Mime
View raw message