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)
