You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2009/05/22 20:59:33 UTC
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
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?
> 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.
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
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, May 22, 2009 at 4:21 PM, Jeff Trawick <tr...@gmail.com> wrote:
>
>
> On Fri, May 22, 2009 at 2:59 PM, William A. Rowe, Jr. <wrowe@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
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, May 22, 2009 at 4:21 PM, Jeff Trawick <tr...@gmail.com> wrote:
>
>
> On Fri, May 22, 2009 at 2:59 PM, William A. Rowe, Jr. <wrowe@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
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, May 22, 2009 at 5:10 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net>wrote:
> 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
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, May 22, 2009 at 5:10 PM, William A. Rowe, Jr.
<wr...@rowe-clan.net>wrote:
> 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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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.
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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.
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
Posted by Jeff Trawick <tr...@gmail.com>.
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
* 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
Posted by Jeff Trawick <tr...@gmail.com>.
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
* 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
*
*/