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=773881&view=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").