Re-sending to include the correct perl.a.o dev list. On Thu, Apr 14, 2016 at 1:25 PM, William A Rowe Jr <wr...@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 <wr...@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 <taka...@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. >>> >> >> >