apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <mt...@apache.org>
Subject Re: svn commit: r746589 - in /apr/apr/trunk: ./ include/ include/arch/unix/ include/arch/win32/ misc/unix/ misc/win32/ threadproc/beos/ threadproc/netware/ threadproc/os2/ threadproc/unix/ threadproc/win32/
Date Mon, 23 Feb 2009 13:58:48 GMT
Joe Orton wrote:
> On Mon, Feb 23, 2009 at 01:16:22PM +0100, Mladen Turk wrote:
>> Joe Orton wrote:
>>> On Sat, Feb 21, 2009 at 08:59:47PM -0000, Mladen Turk wrote:
>>>> Author: mturk
>>>> Date: Sat Feb 21 20:59:46 2009
>>>> New Revision: 746589
>>>> URL: http://svn.apache.org/viewvc?rev=746589&view=rev
>>>> Log:
>>>> Add simple parent/child data exchange for APR processes
>>> 1) another addition to the procattr API which is entirely orthogonal to
>>> the API's purpose.  ick.
>> This can always be made using some different solutions.
>> However this one IMHO is the most portable one.
>> If you think the apr_procattr is the wrong group I can
>> rename it to something else, but it's related to
>> process, process attributes and ipc, so there's not
>> very much space for something meaningful.
> "this HTTP server I just wrote is related to sockets, files, and 
> processes, so I'm going to put it in APR"


> I don't see why it needs to be in APR at all.  APR should not become a 
> random dumping ground for utility functions that someone once found 
> useful; APR-util has to-date served that function quite well.

It cannot be part of apr-util cause it's platform specific.
It is created when we know the child pid but before the child starts.

> The parent doesn't fail on the apr_shm_create() error path, it carries 
> on regardless.  Changing it to fail would downgrade the tmp race from a 
> potential escalation of privileges to a DoS; still a security issue.

Right it should fail if it cannot create the shm.

>> Also shm name is not predictable because the child pid is not
>> known in advance (well one can make all 1...PID_MAX shm's, sure),
> tmp races are a security issue regardless of pid predicatibility (and in 
> fact, pids are predictable on many platforms).

Well, this can be easily fixed by making unique tmpfile
and adding apripc.<PID>=tempfile to the env.


View raw message