Re: support for Apache 2.4
On Thu, Feb 20, 2014 at 3:49 PM, Andy Colson a...@squeakycode.net wrote: On 02/16/2014 09:36 AM, Steve Hay wrote: On 16 February 2014 15:11, Dominic Hargreaves d...@earth.li wrote: On Sun, Feb 16, 2014 at 11:10:20PM +1100, Carl Brewer wrote: Having just downloaded this latest SVN repo, a grep for 2.4 in the root dir shows a couple of changes, but no explicit mention of 2.4 support. Before I try it, does it actually support 2.4 yet? The Debian project is shipping mod_perl with httpd24 support based on http://svn.apache.org/repos/asf/perl/modperl/branches/httpd24/. This appears to be good enough for our needs, so you might like to give it a try (our packages are based on a somewhat older version of that branch, and there seem to be quite a number of changes going in, so it's worth giving that a go. I haven't heard about any current plans for merging this to trunk, though. An update on the state of things regarding httpd-2.4 support in mod_perl: We are working hard to get this done and are 99% of the way there. Both volunteers and volunteers' time is limited, though, so progress has been slow. A lot of work has taken place in the httpd24 branch, and as Dominic says, some Linux distros are already shipping that. Further improvements to mod_perl have also been made in the threading branch, and in a bid to improve the state of httpd-2.4 support on Windows I recently merged the two together in a new branch called httpd24threading. This is where current development activity is taking place, and we are now sufficiently close that I expect this to be merged back to trunk soon. I'm on Slackware64 14.1. svn co http://svn.apache.org/repos/asf/perl/modperl/branches/ httpd24threading/ mod_perl cd mod_perl perl Makefile.PL ... seemed ok ... make ... seed ok... make test make[1]: Leaving directory `/pub/apps/mod_perl/xs' /usr/bin/perl5.18.1 -Iblib/arch -Iblib/lib \ t/TEST -clean [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl5.18.1 /pub/apps/mod_perl/t/TEST -clean APACHE_TEST_GROUP= APACHE_TEST_APXS= APACHE_TEST_HTTPD= APACHE_TEST_USER= APACHE_TEST_PORT= \ /usr/bin/perl5.18.1 -Iblib/arch -Iblib/lib \ t/TEST -bugreport -verbose=0 [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl5.18.1 /pub/apps/mod_perl/t/TEST -bugreport -verbose=0 /usr/sbin/httpd -d /pub/apps/mod_perl/t -f /pub/apps/mod_perl/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS using Apache/2.4.6 (event MPM) waiting 300 seconds for server to start: .httpd: Syntax error on line 97 of /pub/apps/mod_perl/t/conf/httpd.conf: Cannot load /usr/lib64/httpd/modules/mod_apreq2.so into server: /usr/lib64/httpd/modules/mod_apreq2.so: undefined symbol: ap_log_error [ error] server has died with status 255 (t/logs/error_log wasn't created, start the server in the debug mode) sh: line 1: 1523 Terminated /usr/bin/perl5.18.1 /pub/apps/mod_perl/t/TEST -bugreport -verbose=0 make: *** [run_tests] Error 143 Any hints? -Andy /usr/lib64/httpd/modules/mod_apreq2.so isn't built for httpd 2.4, which has no ap_log_error symbol (ap_log_error is a macro that maps to something else). -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: Problem with Apache2::Connection::remote_ip
On Sun, Feb 9, 2014 at 9:40 AM, Steve Hay steve.m@googlemail.comwrote: On 9 February 2014 05:49, Steve Baldwin steve.bald...@gmail.com wrote: Hi, Not sure what I'm doing wrong here. I'm just trying to get the client ip address in a PerlResponseHandler as follows: : use Apache2::Connection; : my $remote_ip = $r-connection-remote_ip(); : I get a runtime error as follows: [Sun Feb 09 16:44:22.499681 2014] [perl:error] [pid 3632] [client 192.168.1.105:52533] Can't locate object method remote_ip via package Apache2::Connection at /usr/local/lib/site_perl/Storm/Dev/Handler.pm Is it called client_ip() now rather than remote_ip()? http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html Search for remote_ip for discussion. Here are the various versions (OS = Ubuntu 13.10) : [Sun Feb 09 16:44:01.267265 2014] [mpm_prefork:notice] [pid 3625] AH00163: Apache/2.4.6 (Ubuntu) PHP/5.5.3-1ubuntu2.1 mod_perl/2.0.8 Perl/v5.14.2 configured -- resuming normal operations mod_perl doesn't officially support httpd 2.4.x yet, but it's getting close now. I think some Linux distros have gone ahead with versions already, which I guess is what you're using. -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: Debugging segmentation fault
On Mon, Sep 2, 2013 at 1:12 PM, Igor Chudov ichu...@gmail.com wrote: I run a busy website algebra.com on a CentOS server. Occasionally, apache processes crash with a segmentation fault. I often get 140+ object requests per second, so isolating which request caused segfault, by looking at logs, is not practicable. I want to know if I can at least isolate the cause of the problem to a URL (webpage) that caused it to crash. A stack dump would be ideal, but if I can get URL and parameters, that would already be very nice. Any suggestions? non-Perl-specific: mod_log_forensic http://httpd.apache.org/docs/2.2/mod/mod_log_forensic.html mod_whatkilledus (usually with mod_backtrace): http://emptyhammock.com/projects/httpd/diag/legacy_exception_hook.html http://emptyhammock.com/projects/httpd/diag/index.html -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: mod_perl and Transfer-Encoding: chunked
On Wed, Jul 3, 2013 at 4:31 PM, Jim Schueler jschue...@eloquency.comwrote: In light of Joe Schaefer's response, I appear to be outgunned. So, if nothing else, can someone please clarify whether de-chunked means re-assembled? yes, where re-assembled means convert it back to the original data stream without any sort of transport encoding -Jim On Wed, 3 Jul 2013, Jim Schueler wrote: Thanks for the prompt response, but this is your question, not mine. I hardly need an RTFM for my trouble. I drew my conclusions using a packet sniffer. And as far-fetched as my answer may seem, it's more plausible than your theory that Apache or modperl is decoding a raw socket stream. The crux of your question seems to be how the request content gets magically re-assembled. I don't think it was ever disassembled in the first place. But if you don't like my answer, and you don't want to ignore it either, then please restate the question. I can't find any definition for unchunked, and Wiktionary's definition of de-chunk says to break apart a chunk, that is (counter-intuitively) chunk a chunk. Second, if there's no Content-Length header then how does one know how much data to read using $r-read? One answer is until $r-read returns zero bytes, of course. But, is that guaranteed to always be the case, even for, say, pipelined requests? My guess is yes because whatever is de-chunking the read() is blocking. So it never returns 0, even in a pipeline request (if no data is available, it simply waits). I don't wish to discuss the merits here, but there is no technical imperative for a content-length request in the request header. -Jim On Wed, 3 Jul 2013, Bill Moseley wrote: Hi Jim, This is the Transfer-Encoding: chunked I was writing about: http://tools.ietf.org/html/**rfc2616#section-3.6.1http://tools.ietf.org/html/rfc2616#section-3.6.1 On Wed, Jul 3, 2013 at 11:34 AM, Jim Schueler jschue...@eloquency.com wrote: I played around with chunking recently in the context of media streaming: The client is only requesting a chunk of data. Chunking is how media players perform a seek. It was originally implemented for FTP transfers: E.g, to transfer a large file in (say 10K) chunks. In the case that you describe below, if no Content-Length is specified, that indicates send the remainder. From what I know, a chunk request header is used this way to specify the server response. It does not reflect anything about the data included in the body of the request. So first, I would ask if you're confused about this request information. Hypothetically, some browsers might try to upload large files in small chunks and the chunk header might reflect a push transfer. I don't know if chunk is ever used for this purpose. But it would require the following characteristics: 1. The browser would need to originally inquire if the server is capable of this type of request. 2. Each chunk of data will arrive in a separate and independent HTTP request. Not necessarily in the order they were sent. 3. Two or more requests may be handled by separate processes simultaneously that can't be written into a single destination. 4. Somehow the server needs to request a resend if a chunk is missing. Solving this problem requires an imaginitive use of HTTP. Sounds messy. But might be appropriate for 100M+ sized uploads. This *may* reflect your situation. Can you please confirm? For a single process, the incoming content-length is unnecessary. Buffered I/O automatically knows when transmission is complete. The read() argument is the buffer size, not the content length. Whether you spool the buffer to disk or simply enlarge the buffer should be determined by your hardware capabilities. This is standard IO behavior that has nothing to do with HTTP chunk. Without a Content-Length header, after looping your read() operation, determine the length of the aggregate data and pass that to Catalyst. But if you're confident that the complete request spans several smaller (chunked) HTTP requests, you'll need to address all the problems I've described above, plus the problem of re-assembling the whole thing for Catalyst. I don't know anything about Plack, maybe it can perform all this required magic. Otherwise, if the whole purpose of the Plack temporary file is to pass a file handle, you can pass a buffer as a file handle. Used to be IO::String, but now that functionality is built into the core. By your last paragraph, I'm really
Re: How to determine what makes Apache crash?
On Thu, Mar 7, 2013 at 9:52 AM, Michiel Beijen michiel.bei...@otrs.comwrote: Hi, I'm using mod_perl 2.0.7 on Windows with Apache 2.2.23. I got Apache from Apachelounge, and compiled mod_perl and perl 5.16.2 myself using Visual Studio 2008. I'm using a 32-bit Windows Vista. Pretty frequently my app (which works just fine on Linux) makes Apache crash. If I perform 500 requests with Apache Bench, I see this: Benchmarking localhost (be patient) Completed 100 requests Completed 200 requests Completed 300 requests apr_socket_recv: An existing connection was forcibly closed by the remote host. (730054) Total of 338 requests completed In the apache error log I see apache is restarting, but this results in some HTTP 500 errors that make the apache-bench results fail. When using a web browser, I also get these http 500 errors. If I run the application using native CGI (i.e. I turn off mod_perl) I do not see crashes but of course it is *very* slow. How can I find out what makes apache/mod_perl crash? I don't see any Windows crash diagnosis information on this page: http://httpd.apache.org/dev/debugging.html Is Dr. Watson still the way to go? mod_backtrace (http://emptyhammock.com/projects/httpd/diag/) may be a shortcut to getting a backtrace. There's a binary for use with Apache 2.2 on Windows in the download package. Any mechanism for getting a backtrace will require that symbol files (.pdb files) matching your Apache httpd build be present. I don't know how the Apache Lounge distributions accommodate that. Some other builds provide a separate .zip with the .pdb files, to be unpacked from the Apache httpd install directory prior to collecting problem documentation. -- Mike -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: How to determine what makes Apache crash?
On Thu, Mar 7, 2013 at 2:43 PM, Michiel Beijen michiel.bei...@otrs.comwrote: On Thu, Mar 7, 2013 at 4:02 PM, Jeff Trawick traw...@gmail.com wrote: mod_backtrace (http://emptyhammock.com/projects/httpd/diag/) may be a shortcut to getting a backtrace. There's a binary for use with Apache 2.2 on Windows in the download package. Any mechanism for getting a backtrace will require that symbol files (.pdb files) matching your Apache httpd build be present. I don't know how the Apache Lounge distributions accommodate that. Some other builds provide a separate .zip with the .pdb files, to be unpacked from the Apache httpd install directory prior to collecting problem documentation. Thanks, your modules look helpful. I asked at the apachelounge for how to get the symbol files. If needed, I'll compile Apache myself. I have output like this from whatkilledus, but of course this does not really help much: http://perlpunks.de/paste/show/5138ecec.24c3.350?plain=1 The symbols within httpd are bogus, and should be corrected with symbol files from Apache Lounge. Perhaps the mod_perl folks can comment on the mod_perl/perl section of the back trace, and how one might try to tie that to some particular area of your code. -- Mike -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: Ubuntu and mod_perl
On Tue, May 17, 2011 at 8:25 PM, silent silent2...@gmail.com wrote: you have compiled and installed one apache, and you made it start at boot time, you must disable it or remove it ( do not let it start at boot time ) 2011/5/18 Tom Kane t.k...@mindspring.com: I tried to incorporate suggestions I've received. After restarting apache2, this is what happened: tomkane@sfq:~$ /etc/init.d/apache2 start * Starting web server apache2 [Tue May 17 20:12:34 2011] [warn] module perl_module is already loaded, skipping (13)Permission denied: make_sock: could not bind to address 0.0.0.0:80 sudo /etc/init.d/apache2 start (or restart if already running)
Re: ExtFilterDefine persistency
On Wed, May 19, 2010 at 6:36 PM, David david_6...@msn.com wrote: If I haven't sent this to the correct place please inform me. I've look through the assorted documentation, both mod_perl and Apache, and haven't found a solution to my situation. I've also given the internet a try with no luck. I admit I'm new to mod_perl. I've installed mod_perl onto an Apache server, version 2.2.15, Windows XP, and have it running. I'm running Perl 5.8.8 I've inserted the following line into my httpd.conf file: ExtFilterDefine IpCount mode=input cmd=C:/perl/bin/perl.exe C:/Apache22/cgi-bin/ip_count.pl. That doesn't use mod_perl. Instead, it launches your script externally in the same manner as a traditional CGI (separate process, no persistence between requests). The file ip_count.pl will execute just fine but because I have to load the Perl interpreter each time, and I can't specify a URL, the performance is less than desired. No persistency. Is there a way to have mod_perl handle its execution by specifying something other than C:/perl/bin/perl.exe? mod_perl and mod_ext_filter don't interact for filtering. mod_perl provides its own filtering interface; it wouldn't be as easy to implement as your simple cmd-line filter, but it would have much higher performance; see http://perl.apache.org/docs/2.0/api/Apache2/Filter.html (I dunno much about mod_perl, but I wrote mod_ext_filter originally.)
Re: perl 5.12 / mod_perl
2010/5/6 Torsten Förtsch torsten.foert...@gmx.net: On Thursday 06 May 2010 13:53:37 tech_list wrote: [ error] '/usr/local/apache2/bin/apxs -q NOTEST_CPPFLAGS' failed: [ error] Use of assignment to $[ is deprecated at /usr/local/apache2/bin/apxs line 86. Okay, I see. My apxs starts with #!/usr/bin/perl -w and this perl is still 5.10.0. Nevertheless apxs is not part of modperl. Best you'd file bug against httpd. In the meantime simply delete line 86 in apxs. $[ is 0 per default. So, Clocal $[=0 is useless. It's usage has been deprecated for a long time. Here's the committed httpd fix: http://svn.apache.org/viewvc/httpd/httpd/trunk/support/apxs.in?r1=807930r2=932791diff_format=h It should be in the next 2.2.x release.
Re: ApacheCon 2009 in Oakland
On Mon, Oct 19, 2009 at 12:15 AM, Fred Moyer f...@redhotpenguin.com wrote: Greetings, Is anyone here attending ApacheCon in Oakland this year? I am organizing a mod_perl social. I'll be at the conference at least one day hacking mod_perl. This lurker will be there.
Re: mp2 / Apache byterange filter
On Thu, Jun 18, 2009 at 10:22 AM, Adriano Caloiaro acalo...@gmail.comwrote:
Hello,
Could someone point me in the correct direction to support byte range
responses in mod_perl2? From what I've read, Apache should understand that
it needs to apply the byterange filter whenever $r-sendfile is used on a
large file and the Range: header is present in the incoming request.
However what I'm seeing is that the entire file is returned for each byte
range requested by the client.
Access log serving off disk in Apache2:
*.*.*.* - - [17/Jun/2009:19:50:30 -0400] GET
/mygcx/test/flvplayernew17.flv HTTP/1.1 206 1 - -
*.*.*.* - - [17/Jun/2009:19:50:31 -0400] GET
/mygcx/test/flvplayernew17.flv HTTP/1.1 206 435996 - -
*.*.*.* - - [17/Jun/2009:19:50:30 -0400] GET
/mygcx/test/flvplayernew17.flv HTTP/1.1 206 2097152 - -
Serving from perl handler:
*.*.*.* - - [18/Jun/2009:10:11:43 -0400] GET
/mygcx/test/flvplayernew17.flv HTTP/1.1 200 2533148 - -
*.*.*.* - - [18/Jun/2009:10:11:45 -0400] GET
/mygcx/test/flvplayernew17.flv HTTP/1.1 200 2533148 - -
*.*.*.* - - [18/Jun/2009:10:11:45 -0400] GET
/mygcx/test/flvplayernew17.flv HTTP/1.1 200 2533148 - -
Maybe these checks are bypassing range processing? (httpd 2.2.x,
byterange_filter.c)
/* Iterate through the brigade until reaching EOS or a bucket with
* unknown length. */
for (e = APR_BRIGADE_FIRST(bb);
(e != APR_BRIGADE_SENTINEL(bb) !APR_BUCKET_IS_EOS(e)
e-length != (apr_size_t)-1);
e = APR_BUCKET_NEXT(e)) {
clength += e-length;
}
/* Don't attempt to do byte range work if this brigade doesn't
* contain an EOS, or if any of the buckets has an unknown length;
* this avoids the cases where it is expensive to perform
* byteranging (i.e. may require arbitrary amounts of memory). */
if (!APR_BUCKET_IS_EOS(e) || clength = 0) {
ap_remove_output_filter(f);
return ap_pass_brigade(f-next, bb);
}
It would seem like re-invited in the wheel if I were to implement RFC 2616
in perl when there is a byterange filter already present in apache. Thank
you for any help!
See if these byterange requirements can be met. (Somebody that knows more
about mod_perl may have to check for you. It depends on how data is passed
to httpd.)
Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS include/http_core.h modules/filters/mod_include.c server/config.c server/core.c
On Thu, May 21, 2009 at 3:25 PM, Jeff Trawick traw...@gmail.com wrote: On Thu, May 21, 2009 at 3:08 PM, William A. Rowe, Jr. wr...@rowe-clan.net wrote: Jeff Trawick wrote: Does somebody else care to share their opinion on this? Which of these are okay? - existing mod_perl releases (and potentially other third-party modules) won't compile with 2.2.12 CORE_PRIVATE may be broken from release to release, it's a necessary concession to prevent utter stagnation :( The bits are not CORE_PRIVATE. You can find sample Perl code on the web that even tests these bits, though it isn't clear to me if that is a normal practice when using the Perl/mod_include interface. Hmmm, after trying to use what seems like a cool feature, I find that mod_perl was never taught to use the Apache 2's mod_include plug-in interface.
Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS include/http_core.h modules/filters/mod_include.c server/config.c server/core.c
On Fri, May 22, 2009 at 2:46 PM, Torsten Foertsch torsten.foert...@gmx.netwrote: On Fri 22 May 2009, Jeff Trawick wrote: Hmmm, after trying to use what seems like a cool feature, I find that mod_perl was never taught to use the Apache 2's mod_include plug-in interface. AFAIK, that is provided by Geoff's CPAN module Apache::IncludeHook or so. Neat, and the use of [SSI_]FLAG_NO_EXEC in the filter context isn't affected by this change. FWIW, it looks like it won't work with httpd 2.2 (IncludeHook.xs uses FLAG_NO_EXEC instead of SSI_FLAG_NO_EXEC) unless there's some compile-time mapping going on somewhere that I don't see.
Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS include/http_core.h modules/filters/mod_include.c server/config.c server/core.c
On Fri, May 22, 2009 at 2:59 PM, William A. Rowe, Jr. wr...@rowe-clan.netwrote: Joe Orton wrote: Having thought about this longer, I do agree that it would be reasonable to provide OPT_INCNOEXEC as a noop integer for back-compat, but, it turns out we're out of bits - allow_options_t is an unsigned char and we're using 2^0 through 2^7 already. :( The C langauge promotes char - int for comparison. 256 should work fine, no? It would devolve to 0, of course, but 256 255 should test fine. Thoughts? Backing up a bit... I originally thought we could map bit values in 2.2.x to avoid affecting modules, but that isn't possible since includes-with-exec is two bits instead of one. Mapping OPT_INCNOEXEC to a no-op integer is something that takes place at compile time, and helps applications which reference the symbol but don't use it in any important way. (IOW, let mod_perl and other similar tarballs compile.) It is good in that it lets mod_perl compile, but bad in that mod_perl continues to export the Perl mapping of OPT_INCNOEXEC even after httpd has been upgraded and at some point later mod_perl is upgraded. Failing the compile is our only opportunity to catch some affected modules (though it is a rather late opportunity since the modules will likely be rebuilt later since they're supposed to work as-is when upgrading httpd; somebody will grumble though). I don't think we should try to preserve compilability if we can't preserve compatibility. The only available option is to #define OPT_INCNOEXEC to some bogus string or something; not sure I like that much better than just a clean break. /* * #define OPT_INCNOEXEC 32 * Apache 2.2.12 and later no longer provide this. * Applications which distinguish between includes-without-exec and includes-with-exec * must use different logic for 2.2.12 and 2.2.=12. * Prior to 2.2.12: * includes-without-exec: OPT_INCNOEXEC flag on, OPT_INCLUDES flag off * includes-with-exec: OPT_INCNOEXEC flag off, OPT_INCLUDES flag on * As of 2.2.12: * includes-without-exec: OPT_INCLUDES flag on, OPT_INC_WITH_EXEC flag off * includes-with-exec: OPT_INCLUDES flag on, OPT_INC_WITH_EXEC flag on * */
Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS include/http_core.h modules/filters/mod_include.c server/config.c server/core.c
On Fri, May 22, 2009 at 4:21 PM, Jeff Trawick traw...@gmail.com wrote: On Fri, May 22, 2009 at 2:59 PM, William A. Rowe, Jr. wr...@rowe-clan.net wrote: Joe Orton wrote: Having thought about this longer, I do agree that it would be reasonable to provide OPT_INCNOEXEC as a noop integer for back-compat, but, it turns out we're out of bits - allow_options_t is an unsigned char and we're using 2^0 through 2^7 already. :( The C langauge promotes char - int for comparison. 256 should work fine, no? It would devolve to 0, of course, but 256 255 should test fine. Thoughts? Backing up a bit... I originally thought we could map bit values in 2.2.x to avoid affecting modules, but that isn't possible since includes-with-exec is two bits instead of one. Mapping OPT_INCNOEXEC to a no-op integer is something that takes place at compile time, and helps applications which reference the symbol but don't use it in any important way. (IOW, let mod_perl and other similar tarballs compile.) It is good in that it lets mod_perl compile, but bad in that mod_perl continues to export the Perl mapping of OPT_INCNOEXEC even after httpd has been upgraded and at some point later mod_perl is upgraded. Failing the compile is our only opportunity to catch some affected modules (though it is a rather late opportunity since the modules will likely be rebuilt later since they're supposed to work as-is when upgrading httpd; somebody will grumble though). I don't think we should try to preserve compilability if we can't preserve compatibility. The only available option is to #define OPT_INCNOEXEC to some bogus string or something; not sure I like that much better than just a clean break. /* * #define OPT_INCNOEXEC 32 * Apache 2.2.12 and later no longer provide this. * Applications which distinguish between includes-without-exec and includes-with-exec * must use different logic for 2.2.12 and 2.2.=12. * Prior to 2.2.12: * includes-without-exec: OPT_INCNOEXEC flag on, OPT_INCLUDES flag off oops, both flags were on here * includes-with-exec: OPT_INCNOEXEC flag off, OPT_INCLUDES flag on * As of 2.2.12: * includes-without-exec: OPT_INCLUDES flag on, OPT_INC_WITH_EXEC flag off * includes-with-exec: OPT_INCLUDES flag on, OPT_INC_WITH_EXEC flag on * */
Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS include/http_core.h modules/filters/mod_include.c server/config.c server/core.c
On Fri, May 22, 2009 at 5:10 PM, William A. Rowe, Jr. wr...@rowe-clan.netwrote: Jeff Trawick wrote: Backing up a bit... I originally thought we could map bit values in 2.2.x to avoid affecting modules, but that isn't possible since includes-with-exec is two bits instead of one. Hold on... I think this can still work; * Retain new true 'Includes' bit as old IncludesNoExec macro value Keep ancient Includes flag bit as 256, never true. - all httpd modules testing for including but not executing permission see the permission as allowed - old httpd modules testing for includes with exec permission see the permission as denied, until they update the module - httpd modules which force/override the includes without exec permission would still work - httpd modules which force/override the includes exec behavior would just fail to update anything (256 0xff == 00), so it becomes a noop until they update the module So it has no negative security consequences, still would require an update to the rare module, but lets us ship something without really nasty side effects. I'll think harder about this once my latest proposal gets shot down ;)
Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS include/http_core.h modules/filters/mod_include.c server/config.c server/core.c
On Wed, May 20, 2009 at 8:53 AM, Joe Orton jor...@redhat.com wrote: On Sun, May 17, 2009 at 11:15:00AM -0400, Jeff Trawick wrote: On Tue, May 12, 2009 at 9:17 AM, cove...@apache.org wrote: Author: covener Date: Tue May 12 13:17:29 2009 New Revision: 773881 URL: http://svn.apache.org/viewvc?rev=773881view=rev Log: backport 772997, 773322, 773342 from trunk. Reviewed By: jorton, rpluem, covener Security fix for CVE-2009-1195: fix Options handling such that 'AllowOverride Options=IncludesNoExec' does not permit Includes with exec= enabled to be configured in an .htaccess file: * include/http_core.h: Change semantics of Includes/IncludeNoExec options bits to be additive; OPT_INCLUDES now means SSI is enabled without exec=. OPT_INCLUDES|OPT_INC_WITH_EXEC means SSI is enabled with exec=. Current mod_perl tarballs reference OPT_INC_WITH_EXEC as part of mapping the httpd API into perl, and the mod_perl build fails because of this. (modperl_config.c, line 525: undefined symbol: OPT_INCNOEXEC) Ick :( For some reason I thought this was hidden by CORE_PRIVATE, for what little that's worth. While I don't understand why the mod_perl mappings are created at release time against who knows what httpd, it brings up an interesting httpd issue anyway. If some module does have OPT_INCNOEXEC baked in (32), it matches what 2.2.12+ thinks is OPT_INC_WITH_EXEC. Similarly, the old OPT_INC_WITH_EXEC (previously called OPT_INCLUDES), maps what 2.2.12+ thinks is OPT_INCLUDES-without-exec. We could swap the values of OPT_INCLUDES and OPT_INC_WITH_EXEC to lessen the chance of some theoretical module making the wrong decision. We can also define OPT_INCNOEXEC to something (either the new OPT_INCLUDES or Get your mod_perl patch at XXX). Given that the semantics of the options has changed, I don't think it's worth changing httpd to maintain any pretence of compile-time or run-time compatibility here. Any code using the OPT_* constants as exposed by mod_perl cannot work as expected any more. Regards, Joe Is the change in semantics required to fix the bug, or is it simply the current implementation? As these constants and the related ap_allow_options() have been exposed to the C API for eons, and passed through in API mappings such as mod_perl, it is worth making an alternate fix to avoid breaking module compiles and (potentially) module misbehavior when upgrading from 2.2.11 to 2.2.12. Unfortunately I don't have a patch :( Does somebody else care to share their opinion on this? Which of these are okay? - existing mod_perl releases (and potentially other third-party modules) won't compile with 2.2.12 - existing Perl modules (and potentially other third-party modules) will confuse include-with-exec and include-without-exec
Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS include/http_core.h modules/filters/mod_include.c server/config.c server/core.c
On Thu, May 21, 2009 at 3:08 PM, William A. Rowe, Jr. wr...@rowe-clan.netwrote: Jeff Trawick wrote: Does somebody else care to share their opinion on this? Which of these are okay? - existing mod_perl releases (and potentially other third-party modules) won't compile with 2.2.12 CORE_PRIVATE may be broken from release to release, it's a necessary concession to prevent utter stagnation :( The bits are not CORE_PRIVATE. You can find sample Perl code on the web that even tests these bits, though it isn't clear to me if that is a normal practice when using the Perl/mod_include interface. I believe it was a mistake that this particular symbol/this particular directive is not a part of the mod_includes internals :( Perhaps, though mod_include does have a plug-in interface and we have this non-internal-detail-sounding function called ap_allow_options(). The include option variants could be interesting to such a plug-in. So given we have a .23 mmn bump, perhaps document this in that section. But the actual behavior of this flag changes significantly and I can't see how to properly maintain mod_perl, deep internal compatibility. The requirement is to fix combinations of option specifications in the main conf file and .htaccess. There's nothing incompatible with mod_perl there. We just can't change the meaning of existing bits.
Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS include/http_core.h modules/filters/mod_include.c server/config.c server/core.c
On Tue, May 12, 2009 at 9:17 AM, cove...@apache.org wrote: Author: covener Date: Tue May 12 13:17:29 2009 New Revision: 773881 URL: http://svn.apache.org/viewvc?rev=773881view=rev Log: backport 772997, 773322, 773342 from trunk. Reviewed By: jorton, rpluem, covener Security fix for CVE-2009-1195: fix Options handling such that 'AllowOverride Options=IncludesNoExec' does not permit Includes with exec= enabled to be configured in an .htaccess file: * include/http_core.h: Change semantics of Includes/IncludeNoExec options bits to be additive; OPT_INCLUDES now means SSI is enabled without exec=. OPT_INCLUDES|OPT_INC_WITH_EXEC means SSI is enabled with exec=. Current mod_perl tarballs reference OPT_INC_WITH_EXEC as part of mapping the httpd API into perl, and the mod_perl build fails because of this. (modperl_config.c, line 525: undefined symbol: OPT_INCNOEXEC) While I don't understand why the mod_perl mappings are created at release time against who knows what httpd, it brings up an interesting httpd issue anyway. If some module does have OPT_INCNOEXEC baked in (32), it matches what 2.2.12+ thinks is OPT_INC_WITH_EXEC. Similarly, the old OPT_INC_WITH_EXEC (previously called OPT_INCLUDES), maps what 2.2.12+ thinks is OPT_INCLUDES-without-exec. We could swap the values of OPT_INCLUDES and OPT_INC_WITH_EXEC to lessen the chance of some theoretical module making the wrong decision. We can also define OPT_INCNOEXEC to something (either the new OPT_INCLUDES or Get your mod_perl patch at XXX).
Re: Vulnerability ?
On Wed, May 6, 2009 at 7:40 AM, Francois Pernet francois.per...@idsa.chwrote: Hi, We have received the following vulnerability report: http://www.securityfocus.com/bid/23192/info I read the changes for the mod_perl versions but did not find anything really clear. We are using mod_perl version 2.0.3 compiled for Suse linux enterprise server 10 sp2 used with apache 2.0.x compiled also (we are not using rpm versions of these packages). Can somebody clarify if the vulnerability still present in version 2.0.3 and if we are obliged to move to version 2.0.4 ? As listed on that securityfocus page, the CVE number is CVE-2007-1349. Checking the Changes files for 2.0.3 and 2.0.4, you'll see that 2.0.4 has a fix for that CVE but 2.0.3 doesn't. So 2.0.3 is vulnerable.
Re: PerlIO :APR / apr_file_open() flag issue
The only issue I could see is if APR_WRITE was addeed
at some point somewhat recently, and this change would break
against older APRs.
APR_READ and/or APR_WRITE has been required since the first APR release.
Here's the logic to check for APR_READ/APR_WRITE back in 1999 (still called
ap_open at that point):
(
http://svn.apache.org/viewvc/apr/apr/branches/0.9.x/file_io/unix/open.c?revision=59512view=markup
)
*if* ((flag APR_READ) (flag APR_WRITE)) {
}
*else* *if* (flag APR_READ) {
}
*else* *if* (flag APR_WRITE) {
}
*else* {
*return* APR_EACCES;
}
-- Forwarded message --
From: Philippe M. Chiasson go...@apache.org
To: Marc Adkins madk...@marchex.com
Date: Mon, 20 Apr 2009 23:51:57 -0400
Subject: Re: PerlIO :APR / apr_file_open() flag issue
On 20/04/09 19:59 , Marc Adkins wrote:
Originally posted to the APR dev list. The response (from jTrawick) was
as follows:
The Perl code that builds the apr_file_open() flags needs to turn on
APR_WRITE.
I think that this patch to mod_perl is what you need:
--- modperl_apr_perlio.c.orig2007-12-31 02:39:50.0 -0500
+++ modperl_apr_perlio.c2009-04-20 19:37:25.954107404 -0400
@@ -85,7 +85,7 @@
switch (*mode) {
case 'a':
-apr_flag = APR_APPEND | APR_CREATE;
+apr_flag = APR_WRITE | APR_CREATE | APR_APPEND;
break;
case 'w':
apr_flag = APR_WRITE | APR_CREATE | APR_TRUNCATE;
The rest of this email is my original post. I would still like a
workaround is one exists.
Looks sensible to me. The only issue I could see is if APR_WRITE was
addeed at some point somewhat recently, and this change would break
against older APRs. Might need a version check of some sort.
Otherwise, +1
signature.asc
Description: PGP signature
