apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
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:03:23 GMT
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.

> > 3) fundamental /tmp race (the temp file name is predictable and hence
> > another local user could create the shm file and populate the data
> > segment which would be picked up by the child) and hence is huge
> > security hole
> Hmm, that's the shared memory, not the actual file.

Not sure what you mean there?  e.g. with APR_USE_SHMEM_MMAP_TMP they are 
one and the same thing

> Nevertheless the parent creates the shm so it will fail
> if it cannot create shm, so the child won't get started.

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.

> 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).

Regards, Joe

View raw message