httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: New segfault with 2.4.20 with mod_perl
Date Thu, 19 May 2016 16:23:33 GMT
Re-sending to include the correct perl.a.o dev list.

On Thu, Apr 14, 2016 at 1:25 PM, William A Rowe Jr <wrowe@rowe-clan.net>
wrote:

> The defect appears to be in t/protocol/TestProtocol/pseudo_http.pm...
>
> First, the handler is registered using
>
>   PerlProcessConnectionHandler TestProtocol::pseudo_http
>
> so its activities are outside of the request handling phase.
>
> Note that this logic has been broken, for a long time;
>
>           <IfVersion > 2.4.1>
>               <IfModule mod_access_compat.c>
>                   Order Deny,Allow
>                   Allow from @servername@
>               </IfModule>
>           </IfVersion>
>
> Where @servername@ is a hostname, this module defect was
> identified in version 2.4.20 when we began using the per-req
> hostname in comparison (based on r->useragent_addr, which
> is obviously is null during part of the read_request phase).
>
> But this module using mod_access_compat during the connection
> phase has been broken for much longer, since Allow from {ip-addr}
> would already have failed since 2.4.1 was released, due to the
> same null r->useragent_addr.
>
> Effectively, mod_access_compat.c never supported per-connection
> IP addresses since it was added.  The fact that it supported
> per-connection hostname comparison was a quirk, and that the
> pseudo_http tests only looked at hostname and not ip comparisons
> was an oversight.
>
> But the module will fail in other manners if attempting to use
> http request_rec processing since that record is never fleshed
> out with the proper read/post_read request hook phases.
>
> My thought is to simply decouple access_compat from this
> module test... opinions?
>
> See also; https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820824;msg=5
>
>
> On Thu, Apr 14, 2016 at 11:55 AM, William A Rowe Jr <wrowe@rowe-clan.net>
> wrote:
>
>> We can be more vigilant about unexpectedly null values, however...
>>
>> how are you running request processing in the connection callback
>> of mod_perl?  That makes no sense, and probably signals a deeper
>> logic error.
>>
>> The access checker is configured per-dir, so until the request rec
>> is completely initialized during read_request, this doesn't make
>> much sense to me (full backtrace .. including frames #6-#10, for
>> those who are curious...)
>>
>> Either the callback list registered for modperl_callback_connection,
>> or the Perl_runops_standard, or the Perl_pp_entersub invoking the
>> run_access_checker hook seem the most suspect here.
>>
>> #0  apr_getnameinfo (hostname=hostname@entry=0x7fd4461ee368, sockaddr=0x0, flags=flags@entry=0)
>>     at /tmp/buildd/apr-1.5.2/network_io/unix/sockaddr.c:663
>> #1  0x000055feaf0f513a in ap_get_useragent_host (r=r@entry=0x7fd4461ee0a0, type=type@entry=3,
>>     str_is_ip=str_is_ip@entry=0x7fd44740c9c4) at core.c:990
>> #2  0x00007fd4519d7212 in find_allowdeny (r=r@entry=0x7fd4461ee0a0, method=method@entry=0,
a=<optimized out>,
>>     a=<optimized out>) at mod_access_compat.c:279
>> #3  0x00007fd4519d74b2 in check_dir_access (r=0x7fd4461ee0a0) at mod_access_compat.c:332
>> #4  0x000055feaf0f8f30 in ap_run_access_checker (r=r@entry=0x7fd4461ee0a0) at request.c:87
>> #5  0x00007fd448a6f7dd in XS_Apache2__RequestRec_run_access_checker (my_perl=0x55feb2964a20,
cv=<optimized out>)
>>     at HookRun.c:235
>> #6  0x00007fd44f5f7e6a in Perl_pp_entersub () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22
>> #7  0x00007fd44f5f0ca6 in Perl_runops_standard () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22
>> #8  0x00007fd44f575f06 in Perl_call_sv () from /usr/lib/x86_64-linux-gnu/libperl.so.5.22
>> #9  0x00007fd44f91ec28 in modperl_callback (my_perl=my_perl@entry=0x55feb2964a20,
handler=0x7fd4461f2750,
>>     p=p@entry=0x7fd4461f2028, r=r@entry=0x0, s=s@entry=0x7fd453ddc628, args=0x55feb3beebd0)
>>     at modperl_callback.c:100
>> #10 0x00007fd44f91f576 in modperl_callback_run_handlers (idx=0, type=type@entry=1,
r=r@entry=0x0,
>>     c=<optimized out>, s=0x7fd453ddc628, pconf=pconf@entry=0x0, plog=0x0, ptemp=0x0,
run_mode=MP_HOOK_RUN_FIRST)
>>     at modperl_callback.c:236
>> #11 0x00007fd44f91fd4f in modperl_callback_connection (idx=<optimized out>,
c=<optimized out>,
>>     run_mode=<optimized out>) at modperl_callback.c:359
>> #12 0x000055feaf10cdf0 in ap_run_process_connection (c=c@entry=0x7fd4461f22b8) at
connection.c:42
>> #13 0x000055feaf10d340 in ap_process_connection (c=c@entry=0x7fd4461f22b8, csd=csd@entry=0x7fd4461f20a0)
>>     at connection.c:226
>> #14 0x00007fd4523f3e6b in process_socket (bucket_alloc=0x7fd4461f0028, my_thread_num=1,
my_child_num=0,
>>     sock=0x7fd4461f20a0, p=0x7fd4461f2028, thd=0x7fd453eb27a0) at worker.c:631
>> #15 worker_thread (thd=0x7fd453eb27a0, dummy=<optimized out>) at worker.c:990
>> #16 0x00007fd453418454 in start_thread (arg=0x7fd44740d700) at pthread_create.c:334
>> #17 0x00007fd453155ecd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
>>
>>
>> Before we chase down a potential non-defect in httpd, any thoughts
>> on the underlying modperl or script logic?
>>
>>
>> On Thu, Apr 14, 2016 at 1:44 AM, Takashi Sato <takashi@tks.st> wrote:
>>
>>> r->useragent_addr is assigned on ap_read_request (http_core.c),
>>> called from ap_process_http_(async_)connection
>>> called from process_connection hook (APR_HOOK_REALLY_LAST).
>>>
>>> The SEGV occured on process_connection hook, maybe before
>>> ap_process_http_(async_)connection,
>>>
>>> #11 0x00007fd44f91fd4f in modperl_callback_connection (idx=<optimized
>>> out>, c=<optimized out>,
>>>     run_mode=<optimized out>) at modperl_callback.c:359
>>> #12 0x000055feaf10cdf0 in ap_run_process_connection
>>> (c=c@entry=0x7fd4461f22b8) at connection.c:42
>>> #13 0x000055feaf10d340 in ap_process_connection
>>> (c=c@entry=0x7fd4461f22b8, csd=csd@entry=0x7fd4461f20a0)
>>>     at connection.c:226
>>>
>>> so r->useragent_addr had not been assigned any value.
>>>
>>
>>
>

Mime
View raw message