httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Robins <dbrob...@davidrobins.net>
Subject BUG: Apache::Cookie saving expired data
Date Fri, 24 Jun 2005 07:08:37 GMT
I just upgraded to the newest Apache2/mod_perl2, which needed 
libapreq2-2.05-dev for Apache2::Request.  Apache 2.0.54, mod_perl 2.0.0, perl 
5.8.6.

The following statement died with an error about err_headers_out:

 Apache2::Cookie->new($r, name => 'blah', value => $sid, expires => '+1D', 
path => '/path')->bake();

Fine, checked the code, found that bake now wants $r (strange to require it 
two places, but OK, it's 'dev'):

 Apache2::Cookie->new($r, name => 'blah', value => $sid, expires => '+1D', 
path => '/path')->bake($r);

But now it's outputting a cookie with path '+1D' (and everything else 
correct).

if I call path() and expires() separately, it's OK.

I put some trace prints in Apache2::Cookie::new (this is the code that sets 
expires and path, name and value are done explicitly):

    while(my ($k, $v) = each %attrs) {
        $k =~ s/^-//;
print STDERR "setting '$k' to '$v'\n";
print STDERR "pre: ".$cookie->as_string()."\n";
        $cookie->$k($v);
print STDERR "post: ".$cookie->as_string()."\n";
    }
    return $cookie;

Oddly, the 'path' value is corrupt before expires() is even called.  I smell 
rodent and look for the C code for path(), finding it in Cookie.xs:

--- begin function ---
char *
path(obj, val=NULL)
    APR::Request::Cookie obj
    char * val
  PREINIT:
    /*nada*/

  CODE:
    RETVAL = (char *)  obj->path;

    if (items > 1) {
        obj->path = (char *) val;
    }
  OUTPUT:
    RETVAL
--- end function ---

C programmers will probably see what's wrong here: copying a volatile pointer 
(aliasing bug).  The char* comes from SvPV_nolen(), which points into the SV, 
in this case $v from the 'each'.  When $v changes, so will the value of path.  
When $v goes out of scope and its PV gets freed, 'val' will be overwritten by 
whatever uses the space.

The same problem occurs in the other generated char* functions, e.g. domain, 
port, comment, etc.

Should the passed-in strings could be allocated space from the Apache pool 
like name and value?  I figure someone else is better positioned to make a 
clean fix, but if not I can look into writing up a patch.

-- 
Dave
Isa. 40:31

Mime
View raw message