Re: Removing Limit and LimitExcept
On Friday 22 October 2010, Roy T. Fielding wrote: > On Oct 21, 2010, at 11:16 AM, William A. Rowe Jr. wrote: > > On 10/21/2010 10:21 AM, Jim Jagielski wrote: > >> All this debate makes me wonder how many people here still > >> *run* and *administer* web sites... How about putting yourself > >> in the shoes of the sys admin before willy-nilly recrafting > >> configs. I do. And major upgrades like 2.0 -> 2.2 or 2.2 -> 2.4 happen much less often (like every 4-5 years) than mistakes with Limit/LimitExcept that lead to sensitive data being unprotected. The fact that a config like this *allows* GET/POST access to /secret for everyone is really broken: Deny from all Allow from all Deny from all I would see it as a good thing if people who use Limit were forced to rethink their configuration. It's also rather telling that Apache infra preferred to create a new module for *.apache.org instead of using Limit/LimitExcept. > When we get to 3.0, we can remove Limit and LimitExcept entirely. > If you want to move trunk to 3.0a right now, that's fine with me. If we make current trunk 3.0, what version bump would you choose for a potential switch to async/serf/whatever, which would completely break API compatibility for modules? I would rather reserve the bump to 3.0 for that step (which may or may not come).
Re: Removing Limit and LimitExcept
On Oct 22, 2010, at 5:56 AM, William A. Rowe Jr. wrote: > On 10/21/2010 8:49 PM, Roy T. Fielding wrote: >> >> So I am currently -1 on the whole idea. I see no need to deprecate >> Limit and LimitExcept. I see considerable harm in removing them >> entirely. I see no harm in introducing new directives that will do >> similar functionality in a better way, documenting those directives >> as the preferred alternative, and modifying our configs accordingly. > > I expected nothing less from you, Lars, Jim and others who would have > approved this broken feature in the first place. > You mean from people who not only develop but also run it and have comprehension regarding the impact of such extensive config changes for a 2.2->2.4 upgrade, right? Thanks. I think, as Roy says, allowing for Limit/LimitExcept, noting that it is deprecated, and creating a new set of directives that allow people to use the "new method", is a much friendlier approach for our users.
Re: Removing Limit and LimitExcept
On 10/21/2010 8:49 PM, Roy T. Fielding wrote: > > So I am currently -1 on the whole idea. I see no need to deprecate > Limit and LimitExcept. I see considerable harm in removing them > entirely. I see no harm in introducing new directives that will do > similar functionality in a better way, documenting those directives > as the preferred alternative, and modifying our configs accordingly. I expected nothing less from you, Lars, Jim and others who would have approved this broken feature in the first place.
Re: Removing Limit and LimitExcept
On Oct 21, 2010, at 11:16 AM, William A. Rowe Jr. wrote: > On 10/21/2010 10:21 AM, Jim Jagielski wrote: >> All this debate makes me wonder how many people here still >> *run* and *administer* web sites... How about putting yourself >> in the shoes of the sys admin before willy-nilly recrafting >> configs. > > I have, and was bit by the nonsensical behavior of Limit (attempting > to SetHandler only on specific methods), which is why I crusade to > eliminate it in its current form, entirely. > > >SetHandler put-handler > > > Funny thing, everything goes to put-handler. The error logs at > loglevel debug have nothing to say about my "stupidity" as an > administrator. Now how is that not totally broken and bogus? Umm, so you tried to use the directive for something that it does not do, never has done, and makes no sense to do ... RTFM. http://httpd.apache.org/docs/2.2/mod/core.html#limit http://httpd.apache.org/docs/2.2/mod/core.html#sethandler http://httpd.apache.org/docs/2.2/mod/mod_actions.html#script It sounds like an excellent feature that almost exists. I simply don't care how many mistaken configs there are in the world when we are talking about breaking configs that are currently correct, including the config we have in trunk and have been shipping since Limit was introduced http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/extra/httpd-userdir.conf.in So I am currently -1 on the whole idea. I see no need to deprecate Limit and LimitExcept. I see considerable harm in removing them entirely. I see no harm in introducing new directives that will do similar functionality in a better way, documenting those directives as the preferred alternative, and modifying our configs accordingly. When we get to 3.0, we can remove Limit and LimitExcept entirely. If you want to move trunk to 3.0a right now, that's fine with me. Roy
Re: Removing Limit and LimitExcept
On 10/21/2010 10:21 AM, Jim Jagielski wrote: > All this debate makes me wonder how many people here still > *run* and *administer* web sites... How about putting yourself > in the shoes of the sys admin before willy-nilly recrafting > configs. I have, and was bit by the nonsensical behavior of Limit (attempting to SetHandler only on specific methods), which is why I crusade to eliminate it in its current form, entirely. SetHandler put-handler Funny thing, everything goes to put-handler. The error logs at loglevel debug have nothing to say about my "stupidity" as an administrator. Now how is that not totally broken and bogus?
Re: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)
Jim Jagielski wrote: > ++1. > > On Oct 19, 2010, at 3:28 PM, Roy T. Fielding wrote: > > > IMO, removing Limit and LimitExcept would require a bump to httpd 3.x, > > since it would break almost all existing configs and introduce security > > holes if the installer is not prepared to rewrite them. > > > > Deprecating Limit and LimitExcept can be done in 2.4.x, which means > > keeping their functionality intact and warning at startup that the > > feature is less good than the new directives. > > > > Roy Big +1 cheers -- Lars Eilebrecht l...@eilebrecht.net
RE: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)
> -Original Message- > From: Jim Jagielski > Sent: Donnerstag, 21. Oktober 2010 17:22 > To: dev@httpd.apache.org > Subject: Re: Removing Limit and LimitExcept (was: svn commit: > r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c) > > All this debate makes me wonder how many people here still > *run* and *administer* web sites... How about putting yourself > in the shoes of the sys admin before willy-nilly recrafting > configs. > +1. I am one of them :-) Regards Rüdiger
Re: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)
All this debate makes me wonder how many people here still *run* and *administer* web sites... How about putting yourself in the shoes of the sys admin before willy-nilly recrafting configs.
Re: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)
++1. On Oct 19, 2010, at 3:28 PM, Roy T. Fielding wrote: > IMO, removing Limit and LimitExcept would require a bump to httpd 3.x, > since it would break almost all existing configs and introduce security > holes if the installer is not prepared to rewrite them. > > Deprecating Limit and LimitExcept can be done in 2.4.x, which means > keeping their functionality intact and warning at startup that the > feature is less good than the new directives. > > Roy >
Re: Removing Limit and LimitExcept
On 10/20/2010 3:20 PM, Stefan Fritsch wrote: > > Another thing to make transition easier would be to include > mod_allowmethods in 2.2.x. Then many users could migrate their config > before upgrading to 2.4. Irrespective of everything else in this thread, that's a grand idea.
Re: Removing Limit and LimitExcept
On 10/20/2010 3:29 PM, Stefan Fritsch wrote: > > BTW, it would be trivial to create a container that > internally just creates an appropriate struct to place into > core_dir_config->condition, just like does. The problem is that > this (and ) does not work in Location scope, but only in > Directory and Server scope. That's a huge problem, and something I plan to solve for locations. It would be good to fix this for If prior to GA as well. Directories are lovely until you being staging outward facing gateways, when you truly need to work out the mechanics up front with no file system underneath.
Re: Removing Limit and LimitExcept
On Tuesday 19 October 2010, William A. Rowe Jr. wrote: > Foolish question, but if acquires "sane" behavior (by > various definitions of the word sane), and replaces the horribly > limited directive, does your position on numbering this > 2.4 vs 3.0 change? BTW, it would be trivial to create a container that internally just creates an appropriate struct to place into core_dir_config->condition, just like does. The problem is that this (and ) does not work in Location scope, but only in Directory and Server scope. On the other hand, if someone implemented a complete container, its infrastructure could also be used to allow in Location scope. That would be very nice, but I don't know the config walking/merging code well enough to have any idea about how to implement it.
Re: Removing Limit and LimitExcept
On Tuesday 19 October 2010, William A. Rowe Jr. wrote: > >> Then fix the insane behavior. > > > > > > > > I don't think that's an option. Changing the behaviour of Limit > > will surely break some users' auth configs in subtle ways, > > which is much worse than a clean break. > > Well, there is a fix. Disallow all cmd's that don't flag > themselves as being 'limit aware'. It will break lots of configs > in very obvious ways, but that those configs worked in the first > place would be a mystery to the administrator :) I think the main issue is not that most directives ignore Limit, but rather the side effect of removing other access restrictions, as Rainer outlined in his mail. But writing code to detect that situation and log a warning doesn't look straightforward at all. Hmm. Maybe this is comparable with OSs disabling executable stack by default. That also breaks software but there is usually a way of restoring the old behaviour. So maybe we could also disable Limit by default and have a EnableDeprecatedAndOftenInsecureLimitDirectives directive ;-) Another thing to make transition easier would be to include mod_allowmethods in 2.2.x. Then many users could migrate their config before upgrading to 2.4.
RE: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)
> -Original Message- > From: Stefan Fritsch > Sent: Dienstag, 19. Oktober 2010 22:33 > To: dev@httpd.apache.org > Subject: Re: Removing Limit and LimitExcept (was: svn commit: > r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c) > > On Tuesday 19 October 2010, Roy T. Fielding wrote: > > On Oct 19, 2010, at 12:46 PM, Stefan Fritsch wrote: > > > On Tuesday 19 October 2010, Roy T. Fielding wrote: > > >> IMO, removing Limit and LimitExcept would require a bump to > > >> httpd 3.x, since it would break almost all existing configs and > > >> introduce security holes if the installer is not prepared to > > >> rewrite them. > > > > > > If the user is not prepared to change the config, httpd will not > > > start. The user would need to comment out the Limit/LimitExcept > > > lines, but in this case it would be absolutely obvious that he > > > breaks his auth config. > > > > > > And keeping Limit/LimitExcept is bad for security, too, because > > > it has such insane behaviour. See > > > > > > https://issues.apache.org/bugzilla/show_bug.cgi?id=47019 > > > https://issues.apache.org/bugzilla/show_bug.cgi?id=25057 > > > https://issues.apache.org/bugzilla/show_bug.cgi?id=49927 > > > > Then fix the insane behavior. > > I don't think that's an option. Changing the behaviour of Limit will > surely break some users' auth configs in subtle ways, which is much > worse than a clean break. The question is how it breaks users auth configs. If it results in more restrictive behaviour I guess this would be acceptable. > > > >> Deprecating Limit and LimitExcept can be done in 2.4.x, which > > >> means keeping their functionality intact and warning at startup > > >> that the feature is less good than the new directives. > > > > > > If we just add a warning, I fear that many users will still use > > > it even in new installations, because there are so many outdated > > > howtos around. > > > > Of course they will still use it. If you want to mandate config > > changes, then release it as httpd 3.x. Keeling over a website when > > they perform a *minor* version upgrade is foolish. Version numbers > > are cheap. > > I disagree and think that the change is small enough for 2.2->2.4. There are a lot of AAA changes between 2.2 and 2.4, but we tried to provide the users with the option to keep the old syntax in their config e.g. via mod_access_compat. So I do not think that removing Limit between 2.2 and 2.4 without deprecating it before is a good idea. The annoying warning at the start gives users a chance to adjust their config over time. If they don't do that until 2.6 or 3.0, then it is their own fault. Regards Rüdiger
Re: Removing Limit and LimitExcept
On 19.10.2010 22:30, William A. Rowe Jr. wrote: On 10/19/2010 3:03 PM, Roy T. Fielding wrote: Of course they will still use it. If you want to mandate config changes, then release it as httpd 3.x. Keeling over a website when they perform a *minor* version upgrade is foolish. Version numbers are cheap. The auth config / requires changes significantly already between 2.0, 2.2, and 2.4, so they already have to modify their configurations. Right, although not very nice to users the AAA behaviour changed already in the past and I think the gains in this case outweighted the annoyance. Concerning Limit I agree, that there is a huge risk that users don't know about the bad side effects. They intend to restrict access but are not aware that they might remove other explicitely configured access restrictions by that. I remember very well how astonished I was when I first ran into those side effects. So I agree with removing and in this case forcing users to rethink their configuration. IMHO most users do not expect 100% configuration compatibility when switching from 2.0 to 2.2 or 2.2 to 2.4. Of course we should provide a helpful docs page about configuration incompatibilities. Regards, Rainer
Re: Removing Limit and LimitExcept
On 10/19/2010 3:32 PM, Stefan Fritsch wrote: > On Tuesday 19 October 2010, Roy T. Fielding wrote: >> >> Then fix the insane behavior. > > I don't think that's an option. Changing the behaviour of Limit will > surely break some users' auth configs in subtle ways, which is much > worse than a clean break. Well, there is a fix. Disallow all cmd's that don't flag themselves as being 'limit aware'. It will break lots of configs in very obvious ways, but that those configs worked in the first place would be a mystery to the administrator :)
Re: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)
On Tuesday 19 October 2010, Roy T. Fielding wrote: > On Oct 19, 2010, at 12:46 PM, Stefan Fritsch wrote: > > On Tuesday 19 October 2010, Roy T. Fielding wrote: > >> IMO, removing Limit and LimitExcept would require a bump to > >> httpd 3.x, since it would break almost all existing configs and > >> introduce security holes if the installer is not prepared to > >> rewrite them. > > > > If the user is not prepared to change the config, httpd will not > > start. The user would need to comment out the Limit/LimitExcept > > lines, but in this case it would be absolutely obvious that he > > breaks his auth config. > > > > And keeping Limit/LimitExcept is bad for security, too, because > > it has such insane behaviour. See > > > > https://issues.apache.org/bugzilla/show_bug.cgi?id=47019 > > https://issues.apache.org/bugzilla/show_bug.cgi?id=25057 > > https://issues.apache.org/bugzilla/show_bug.cgi?id=49927 > > Then fix the insane behavior. I don't think that's an option. Changing the behaviour of Limit will surely break some users' auth configs in subtle ways, which is much worse than a clean break. > >> Deprecating Limit and LimitExcept can be done in 2.4.x, which > >> means keeping their functionality intact and warning at startup > >> that the feature is less good than the new directives. > > > > If we just add a warning, I fear that many users will still use > > it even in new installations, because there are so many outdated > > howtos around. > > Of course they will still use it. If you want to mandate config > changes, then release it as httpd 3.x. Keeling over a website when > they perform a *minor* version upgrade is foolish. Version numbers > are cheap. I disagree and think that the change is small enough for 2.2->2.4.
Re: Removing Limit and LimitExcept
On 10/19/2010 3:03 PM, Roy T. Fielding wrote: > > Of course they will still use it. If you want to mandate config > changes, then release it as httpd 3.x. Keeling over a website when > they perform a *minor* version upgrade is foolish. Version numbers > are cheap. The auth config / requires changes significantly already between 2.0, 2.2, and 2.4, so they already have to modify their configurations. Foolish question, but if acquires "sane" behavior (by various definitions of the word sane), and replaces the horribly limited directive, does your position on numbering this 2.4 vs 3.0 change?
Re: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)
On Oct 19, 2010, at 12:46 PM, Stefan Fritsch wrote: > On Tuesday 19 October 2010, Roy T. Fielding wrote: >> IMO, removing Limit and LimitExcept would require a bump to httpd >> 3.x, since it would break almost all existing configs and >> introduce security holes if the installer is not prepared to >> rewrite them. > > If the user is not prepared to change the config, httpd will not > start. The user would need to comment out the Limit/LimitExcept lines, > but in this case it would be absolutely obvious that he breaks his > auth config. > > And keeping Limit/LimitExcept is bad for security, too, because it has > such insane behaviour. See > > https://issues.apache.org/bugzilla/show_bug.cgi?id=47019 > https://issues.apache.org/bugzilla/show_bug.cgi?id=25057 > https://issues.apache.org/bugzilla/show_bug.cgi?id=49927 Then fix the insane behavior. >> Deprecating Limit and LimitExcept can be done in 2.4.x, which means >> keeping their functionality intact and warning at startup that the >> feature is less good than the new directives. > > If we just add a warning, I fear that many users will still use it > even in new installations, because there are so many outdated howtos > around. Of course they will still use it. If you want to mandate config changes, then release it as httpd 3.x. Keeling over a website when they perform a *minor* version upgrade is foolish. Version numbers are cheap. Roy
Re: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)
On Tuesday 19 October 2010, Roy T. Fielding wrote: > IMO, removing Limit and LimitExcept would require a bump to httpd > 3.x, since it would break almost all existing configs and > introduce security holes if the installer is not prepared to > rewrite them. If the user is not prepared to change the config, httpd will not start. The user would need to comment out the Limit/LimitExcept lines, but in this case it would be absolutely obvious that he breaks his auth config. And keeping Limit/LimitExcept is bad for security, too, because it has such insane behaviour. See https://issues.apache.org/bugzilla/show_bug.cgi?id=47019 https://issues.apache.org/bugzilla/show_bug.cgi?id=25057 https://issues.apache.org/bugzilla/show_bug.cgi?id=49927 > Deprecating Limit and LimitExcept can be done in 2.4.x, which means > keeping their functionality intact and warning at startup that the > feature is less good than the new directives. If we just add a warning, I fear that many users will still use it even in new installations, because there are so many outdated howtos around.
Re: Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)
IMO, removing Limit and LimitExcept would require a bump to httpd 3.x, since it would break almost all existing configs and introduce security holes if the installer is not prepared to rewrite them. Deprecating Limit and LimitExcept can be done in 2.4.x, which means keeping their functionality intact and warning at startup that the feature is less good than the new directives. Roy
Removing Limit and LimitExcept (was: svn commit: r1023227 - in /httpd/httpd/trunk: CHANGES server/core.c)
On Tuesday 19 October 2010, William A. Rowe Jr. wrote:
> On 10/19/2010 12:47 PM, Stefan Fritsch wrote:
> > On Tuesday 19 October 2010, William A. Rowe Jr. wrote:
> >> If it will be gone, let's get rid of it now. Now that you have
> >> the allowmethod module added, it seems we have sufficient
> >> control paths that will allow users to constrain the accepted
> >> methods, right?
> >>
> >> may still prove useful, but the old was so
> >> constrained that I think we have that old functionality covered,
> >> now.
> >
> > Fine with me. I have reverted r1023227.
>
> Did the removelimit sandbox look good to you, or did we have any
> further changes before we drop that feature?
>
> http://svn.apache.org/viewvc/httpd/sandbox/replacelimit/
>
> Comments sought - if we don't have any objections or changes to
> this fork, I know of at least three committers who believe its
> time already, at least with the addition o the allowmethod module,
> eval conditionals and lua.
I have noticed that there are many failures in t/modules/access.t
because of "AllowOverride Limit" being ignored. In this case, many
requests that should have been denied have been allowed. Should we
keep "AllowOverride Limit" as alias for "AllowOverride AuthConfig"? Of
course the deprecation warning should be kept.
Apart from that, I am fine with the removelimit sandbox. Attached is a
patch to make the test framework work.
Index: t/conf/extra.conf.in
===
--- t/conf/extra.conf.in (Revision 1024343)
+++ t/conf/extra.conf.in (Arbeitskopie)
@@ -261,7 +261,12 @@
-AllowOverride Limit
+= 2.3.9>
+AllowOverride AuthConfig
+
+
+AllowOverride Limit
+
Index: c-modules/test_apr_uri/mod_test_apr_uri.c
===
--- c-modules/test_apr_uri/mod_test_apr_uri.c (Revision 1024343)
+++ c-modules/test_apr_uri/mod_test_apr_uri.c (Arbeitskopie)
@@ -275,7 +275,11 @@
unsigned total_failures;
int i;
+#if OR_LIMIT == OR_AUTHCFG
+r->allowed_methods.method_mask |= (AP_METHOD_BIT << M_GET);
+#else
r->allowed |= (AP_METHOD_BIT << M_GET);
+#endif
if (r->method_number != M_GET)
return DECLINED;
Index: c-modules/random_chunk/mod_random_chunk.c
===
--- c-modules/random_chunk/mod_random_chunk.c (Revision 1024343)
+++ c-modules/random_chunk/mod_random_chunk.c (Arbeitskopie)
@@ -117,7 +117,11 @@
return DECLINED;
}
+#if OR_LIMIT == OR_AUTHCFG
+r->allowed_methods.method_mask |= (AP_METHOD_BIT << M_GET);
+#else
r->allowed |= (AP_METHOD_BIT << M_GET);
+#endif
if (r->method_number != M_GET) {
return DECLINED;
Re: PR 47019 Limit/LimitExcept bug or documentation bug?
On Sunday 01 November 2009, Nick Kew wrote: > On 31 Oct 2009, at 23:14, Stefan Fritsch wrote: > > Hi, > > > > consider this config: > > === > > > > [chop] > > > > [chop] > > === > > > > From the LimitExcept docs, I would expect that the > > block does not affect GET/POST requests at all. But actually, it > > is allowing access from everywhere, overriding the previous > > block. > > http://httpd.apache.org/docs/2.2/sections.html#mergin > I am aware that directives in the section override directives in the earlier section. But the does _not_ contain anything that affects GET/POST. Therefore I would expect that the section still applies for GET/POST. The problem is that ... some access control ... is treated as ... some access control ... Allow from all but this is not obvious from the documentation. And it makes it a PITA to globally disallow certain methods (except if using mod_rewrite).
Re: PR 47019 Limit/LimitExcept bug or documentation bug?
On 31 Oct 2009, at 23:14, Stefan Fritsch wrote: Hi, consider this config: === [chop] [chop] === From the LimitExcept docs, I would expect that the block does not affect GET/POST requests at all. But actually, it is allowing access from everywhere, overriding the previous block. http://httpd.apache.org/docs/2.2/sections.html#mergin -- Nick Kew
PR 47019 Limit/LimitExcept bug or documentation bug?
Hi, consider this config: === Order deny,allow Deny from all Allow from 1.2.3.4 Order allow,deny Deny from all === From the LimitExcept docs, I would expect that the block does not affect GET/POST requests at all. But actually, it is allowing access from everywhere, overriding the previous block. It this a bug in httpd or a documentation problem? I would argue it is a httpd bug because it can easily open security holes in a configuration. PR 47019 is filed against 1.3, but the issue affects 2.x/trunk, too. Cheers, Stefan
limitexcept
So auth changing folks, what replaces limitexcept? It's not working on trunk at present as far as I can tell... david
