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.

Regards
-- 
^(TM)