[PATCH] Re: mod_cern_meta/1500: mod_cern_meta corrupts memory pool (fwd)

[Dean Gaudet <dg...@arctic.org>]

This is true for 1.2.x and 1.3.

I would really appreciate it if someone would:

- Check for other instances of improperly assigning memory allocated
    from r->pool to r->connection.  This could quite easily explain
    some random SEGVs that some folk see.

- Find out why the heck the auth crud is stored in r->connection.
  Double check that it's properly reset after each during a keepalive
  session.

Thanks
Dean

---------- Forwarded message ----------
Date: 8 Dec 1997 22:40:01 -0000
To: apache-bugdb@apache.org
Cc: apache-bugdb@apache.org,
From: Dean Gaudet <dg...@arctic.org>
Subject: Re: mod_cern_meta/1500: mod_cern_meta corrupts memory pool

The following reply was made to PR mod_cern_meta/1500; it has been noted by GNATS.

From: Dean Gaudet <dg...@arctic.org>
To: Joe Condon <jo...@unn.unisys.com>
Cc: Roy Wood <ro...@unn.unisys.com>, apbugs@apache.org
Subject: Re: mod_cern_meta/1500: mod_cern_meta corrupts memory pool
Date: Mon, 8 Dec 1997 14:42:44 -0800 (PST)

   This message is in MIME format.  The first part should be readable text,
   while the remaining parts are likely unreadable without MIME-aware tools.
   Send mail to mime@docserver.cac.washington.edu for more info.
 
 --0__=YWpV06K7bc6q4UQbyk4u2g9kNrssA6hy8vcEy3xVm1mHiQDnJDlBW5zv
 Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1
 Content-ID: <Pi...@twinlark.arctic.org>
 
 On Mon, 8 Dec 1997, Joe Condon wrote:
 
 > r->connection->user value is the value that is getting hammered. This value
 > is set in the http_protocol.c source file in function get_basic_auth_pw()
 > at approximately line 1019.
 > 
 > 1019 r->connection->user = getword_nulls_nc(r->pool, &t, ?:?);
 > 
 > Storage allocation for this value occurs in the getword_nulls_nc() function
 > and it is allocated from the memory pool r->pool passed to the function.
 
 Excellent, thanks for looking into this in such depth.  The problem is
 that those allocations clearly should be made from r->connection->pool,
 because they have the same lifetime as r->connection.  Try this patch. 
 
 Dean
 
 --- http_protocol.c.dist	Mon Dec  8 14:29:51 1997
 +++ http_protocol.c	Mon Dec  8 14:35:26 1997
 @@ -935,7 +935,11 @@
      }
  
      t = uudecode (r->pool, auth_line);
 -    r->connection->user = getword_nulls_nc (r->pool, &t, ':');
 +    /* Note that this allocation has to be made from r->connection->pool
 +     * because it has the lifetime of the connection.  The other allocations
 +     * are temporary and can be tossed away any time.
 +     */
 +    r->connection->user = getword_nulls_nc (r->connection->pool, &t, ':');
      r->connection->auth_type = "Basic";
  
      *pw = t;
 
 --0__=YWpV06K7bc6q4UQbyk4u2g9kNrssA6hy8vcEy3xVm1mHiQDnJDlBW5zv--

Re: [PATCH] Re: mod_cern_meta/1500: mod_cern_meta corrupts memory pool (fwd)

[Alexei Kosut <ak...@leland.Stanford.EDU>]

On Mon, 8 Dec 1997, Dean Gaudet wrote:

> - Find out why the heck the auth crud is stored in r->connection.
>   Double check that it's properly reset after each during a keepalive
>   session.

Because way back when, around the time of Apache 0.8, when persistent
connections were first being talked about, the theory was that
authentication (and possibly other headers) would be sticky, that it would
roll over from one request to another, without needing to be
reauthenticated. Looking ahead to the future, the auth information was put
into r->connection, presuming that that would be a good place for it in
the future (but remember that at the time, there was only one request per
connection).

When the keep-alive protocol, and later HTTP/1.1, was finally written, the
idea of sticky headers was dropped (although I think there may be an I-D
on it still out there). When I implemented keep-alive in Apache 1.1, I
didn't want to deal with changing all the authentication stuff to move it
from the connection structure to the request one (originally, the
keep-alive stuff was just a loop in standalone_main() and a few lines in
send_http_header(). It got a lot more complicated later, but at first it
was very simple), so I just NULLed them in between each request. It seemed
easier.

-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
   Stanford University, Class of 2001 * Apache <http://www.apache.org> *