Bug 83202 - apache rewrite-maps (prg) are not thread-safe
Summary: apache rewrite-maps (prg) are not thread-safe
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: apache
Version: 7.3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-31 06:51 UTC by Dave Miller
Modified: 2007-04-18 16:50 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-02-03 09:22:31 UTC

Attachments (Terms of Use)

Description Dave Miller 2003-01-31 06:51:46 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3b) Gecko/20030112

Description of problem:
We use a program as a rewrite map for /~user/ directories on our Apache because
not all users are allowed to have webspace.  The program checks to see if the
user is a member of the appropriate group, and returns a redirect into a "user
doesn't have webspace" type page if they aren't in it.

We just recently migrated this server from RedHat 6.2 to RedHat 7.3, running
apache-1.3.27-2 and immediately started having trouble with images showing up in
the wrong places on web pages.  The correct images would load, but they would be
scrambled as far as what position on the web page they showed up in.  It would
always load the correct HTML, just the images would be screwed up.  The fact
that the correct HTML loaded led me to believe the rewrite map program itself
was not at fault, because it could care less what file was being requested, and
if it was at fault it would scramble everything, including the HTML, so I began
to look elsewhere.

As an experiment, I set MaxServers to 1 (it's normally at 150) so that there
could never be more than one httpd server running.  This solved the image
problem, everything showed up in the correct places.  This seems to imply that
Apache is not handing the rewrite program results back to the same thread that
requested it, but to a seemingly random thread.  The MaxServers 1 workaround
isn't something I can keep because we get too much load to leave it that way (it
only worked for my test because it's 1:30 in the morning so the traffic is low).

I started trying older and older versions of Apache to try to determine where
the error was introduced (since we know it worked fine on our 6.2 box), and
finally got everything working after installing apache-1.3.22-5.7.1.i386.rpm out
of the 7.0 updates tree (actually rebuilt it from the SRPM due to being on 7.3).  

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.use a program for a rewrite map
2.load a page within the portion of the site handled by that map that contains

Actual Results:  The images are scrambled

Expected Results:  The images should be displayed in the correct places.

Additional info:

Setting severity for security because:
1) the newest RPM of apache I can find that works correctly is not secure.
2) by returning the image file paths to the wrong threads, confidential images
on secure web pages could inadvertently be sent to the wrong user

Comment 1 Mark J. Cox 2003-02-03 09:03:56 UTC
Apache runs each child in a separate process (not thread), each Apache child
process runs it's own copy of the rewrite map program.  These errors occur
sometimes when the rewrite map program being used is making the assumption that
it is receiving all the requests (and therefore trying to keep state).

There is a known bug in mod_rewrite that can throw off the ordering if embedded
newline characters are part of the URL, see the below bug.

Comment 2 Dave Miller 2003-02-03 09:22:31 UTC
There is only one copy of the rewrite program running, per 'ps axww', at any
given time, no matter how many httpd processes there are.  The docs for
mod_rewrite explicitly state that it's only started once.

See http://httpd.apache.org/docs/mod/mod_rewrite.html#RewriteMap

However, in examining those docs to get you that proof, I also notice the
RewriteLock directive, which we weren't using.  I don't remember seeing that
before, and it obviously worked without it in the older versions of Apache, so
maybe it's something new.

It does work just fine with that RewriteLock directive in place.

So this is "NOTABUG", but an RTFM.

Note You need to log in before you can comment on or make changes to this bug.