Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 83202 - apache rewrite-maps (prg) are not thread-safe
apache rewrite-maps (prg) are not thread-safe
Product: Red Hat Linux
Classification: Retired
Component: apache (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-01-31 01:51 EST by Dave Miller
Modified: 2007-04-18 12:50 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-02-03 04:22:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dave Miller 2003-01-31 01:51:46 EST
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 04:03:56 EST
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 04:22:31 EST
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.