You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2010/09/14 15:41:53 UTC
DO NOT REPLY [Bug 49927] New: Explanation of the #limit directive
https://issues.apache.org/bugzilla/show_bug.cgi?id=49927
Summary: Explanation of the #limit directive
Product: Apache httpd-2
Version: 2.3-HEAD
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: minor
Priority: P2
Component: Documentation
AssignedTo: bugs@httpd.apache.org
ReportedBy: olivier.pons@gmail.com
Here :
http://httpd.apache.org/docs/2.0/mod/core.html#limit
Someone wrote:
The purpose of the <Limit> directive is to restrict the effect of the access
controls to the nominated HTTP methods. For all other methods, the access
restrictions that are enclosed in the <Limit> bracket will have no effect. The
following example applies the access control only to the methods POST, PUT, and
DELETE, leaving all other methods unprotected:
Shouldn't it be:
"leaving all other methods untouched"
?
(i.e. if there already are some protections on GET there will be untouched)
?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 49927] Explanation of the #limit directive
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49927
--- Comment #2 from Stefan Fritsch <sf...@sfritsch.de> 2010-09-18 05:53:20 EDT ---
see e.g. bug 25057 or bug 47019 which are on httpd 1.3 but affect 2.x as well
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 49927] Explanation of the #limit directive
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49927
Stefan Fritsch <sf...@sfritsch.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|minor |normal
--- Comment #1 from Stefan Fritsch <sf...@sfritsch.de> 2010-09-18 05:46:48 EDT ---
(In reply to comment #0)
> DELETE, leaving all other methods unprotected:
>
> Shouldn't it be:
>
> "leaving all other methods untouched"
>
> ?
No, the current documentation is correct. The semantics of Limit/LimitExcept is
just insane. We should relly get rid if it in 2.4 and improve the docs for 2.2.
Maybe the "unprotected" should be big, red, and blinking ;-)
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
Re: Remove and ?
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Sunday 19 September 2010, Ruediger Pluem wrote:
> On 09/19/2010 12:45 AM, Stefan Fritsch wrote:
> > What do other people think about removing <Limit> and
> > <LimitExcept> and adding mod_allowmethods from the sandbox to
> > easily forbid some methods? Or would this create too much
> > trouble when upgrading configurations?
> >
> > BTW, we could also add an authz provider to allow things like
> >
> > Require method GET,HEAD,...
> >
> > Though this would be slower than mod_allowmethods because authz
> > providers have to parse the require line on every request.
This is done, including parsing the require line only once, which has
the added benefit of catching typos while reading the config.
I would still add mod_allowmethods, because it is really nice for
globally disabling some methods while not having to worry about authz
section merging. Anybody disagrees?
> Hm. I don't like it to be removed until be have an agreed
> alternative in trunk. And the question is whether we should still
> do this after we had a first beta release.
Sounds reasonable. But if we intend to remove Limit/LimitExcept in 2.4
but leave it in the first beta, it should log a really big warning
that it will be removed in 2.4.
Re: Remove and ?
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Sunday 19 September 2010, Paul Querna wrote:
> This is the module that infrastructure uses (and I wrote) to
> replace use of limits on *.apache.org:
> <https://svn.apache.org/repos/infra/infrastructure/trunk/projects/m
> od_allowmethods/mod_allowmethods.c>
>
> It was written after the last attack on our servers in which the
> attackers uploaded CGI scripts; We have some specific use cases
> where we want to allow CGI in some places, but all of them have
> very limited methods they should accept. Trying to configure
> <Limit for our use case and diverse set of vhosts would of meant
> duplicating the config in hundreds of places. I don't think the
> module is really great as an alternative, but it is one path to
> consider, and is working for at least one use case :)
Yes, Igor Galic has commited it here and has written some docs:
http://svn.apache.org/viewvc/httpd/sandbox/mod_allowmethods/
I agree that it is useful for some use cases but is not enough as a
complete Limit/LimtExcept replacement. In any case, I am in favour of
adding it to trunk.
Re: Remove and ?
Posted by Paul Querna <pa...@querna.org>.
On Sun, Sep 19, 2010 at 8:40 AM, Ruediger Pluem <rp...@apache.org> wrote:
>
>
> On 09/19/2010 12:45 AM, Stefan Fritsch wrote:
>> This is from https://issues.apache.org/bugzilla/show_bug.cgi?id=49927
>>
>> On Saturday 18 September 2010, bugzilla@apache.org wrote:
>>> --- Comment #3 from Nick Kew <ni...@webthing.com> 2010-09-18
>>> 06:38:34 EDT ---
>>>
>>>> No, the current documentation is correct. The semantics of
>>>> Limit/LimitExcept is just insane. We should relly get rid if it
>>>> in 2.4 and improve the docs for 2.2. Maybe the "unprotected"
>>>> should be big, red, and blinking ;-)
>>> Agreed. We can even document it as superseded by
>>> <If "$request-method ...">
>>> having of course checked the expression parser, which probably
>>> needs updating to support things like
>>> "... in GET,HEAD,OPTIONS,TRACE"
>>> without some nasty great OR expression.
>>
>> What do other people think about removing <Limit> and <LimitExcept>
>> and adding mod_allowmethods from the sandbox to easily forbid some
>> methods? Or would this create too much trouble when upgrading
>> configurations?
>>
>>
>> BTW, we could also add an authz provider to allow things like
>>
>> Require method GET,HEAD,...
>>
>> Though this would be slower than mod_allowmethods because authz
>> providers have to parse the require line on every request.
>
> Hm. I don't like it to be removed until be have an agreed alternative
> in trunk. And the question is whether we should still do this after
> we had a first beta release.
This is the module that infrastructure uses (and I wrote) to replace
use of limits on *.apache.org:
<https://svn.apache.org/repos/infra/infrastructure/trunk/projects/mod_allowmethods/mod_allowmethods.c>
It was written after the last attack on our servers in which the
attackers uploaded CGI scripts; We have some specific use cases where
we want to allow CGI in some places, but all of them have very limited
methods they should accept. Trying to configure <Limit for our use
case and diverse set of vhosts would of meant duplicating the config
in hundreds of places. I don't think the module is really great as an
alternative, but it is one path to consider, and is working for at
least one use case :)
Re: Remove and ?
Posted by Ruediger Pluem <rp...@apache.org>.
On 09/19/2010 12:45 AM, Stefan Fritsch wrote:
> This is from https://issues.apache.org/bugzilla/show_bug.cgi?id=49927
>
> On Saturday 18 September 2010, bugzilla@apache.org wrote:
>> --- Comment #3 from Nick Kew <ni...@webthing.com> 2010-09-18
>> 06:38:34 EDT ---
>>
>>> No, the current documentation is correct. The semantics of
>>> Limit/LimitExcept is just insane. We should relly get rid if it
>>> in 2.4 and improve the docs for 2.2. Maybe the "unprotected"
>>> should be big, red, and blinking ;-)
>> Agreed. We can even document it as superseded by
>> <If "$request-method ...">
>> having of course checked the expression parser, which probably
>> needs updating to support things like
>> "... in GET,HEAD,OPTIONS,TRACE"
>> without some nasty great OR expression.
>
> What do other people think about removing <Limit> and <LimitExcept>
> and adding mod_allowmethods from the sandbox to easily forbid some
> methods? Or would this create too much trouble when upgrading
> configurations?
>
>
> BTW, we could also add an authz provider to allow things like
>
> Require method GET,HEAD,...
>
> Though this would be slower than mod_allowmethods because authz
> providers have to parse the require line on every request.
Hm. I don't like it to be removed until be have an agreed alternative
in trunk. And the question is whether we should still do this after
we had a first beta release.
Regards
Rüdiger
Re: Remove and ?
Posted by Stefan Fritsch <sf...@sfritsch.de>.
A suggested patch is at
http://people.apache.org/~sf/remove-limit.diff
Re: Remove and ?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 9/20/2010 11:15 AM, William A. Rowe Jr. wrote:
>
> If noone objects, I'll fork the sandbox for this experiment later this evening.
This now exists under https://svn.apache.org/repos/asf/httpd/sandbox/replacelimit/
It doesn't yet contain a <Method > proposal at r999750, so feel free to look at
simply the (complete?) removal of <Limit > mechanics, and I'll start committing
the replacement in the coming days.
Just messed with mod_allowmethods, and although it has one small flaw (which
should have respected an apr_int64_t worth of methods), it is primarily bound
up in the ancient ap_hook_access_checker semantics, and is probably easily
ported.
Re: Remove and ?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 9/20/2010 11:12 AM, William A. Rowe Jr. wrote:
> On 9/18/2010 5:45 PM, Stefan Fritsch wrote:
>>
>> What do other people think about removing <Limit> and <LimitExcept>
>> and adding mod_allowmethods from the sandbox to easily forbid some
>> methods? Or would this create too much trouble when upgrading
>> configurations?
>
> The unfinished bit of that patch is deciding how and where the section
> merge will occur. Since it's a NTP that could lead to some degree of
> confusion about scoping, it really seems like that should happen every
> time a per-dir merge occurs.
>
> What I'm thinking of for the solution is to have a post-merge hook, so
> that remerges can occur for any registered section provider. The whole
> <Files > merge could become one consumer of this hook. That hook would,
> of course, return a newly merged section or the identity of the source
> dir config, if everyone declines. It's recursive, in that you could
> end up with a nested Files in a location, which in turn has nested methods
> which are acceptable.
>
> Does anyone have thoughts on the best way to handle per-dir nesting?
I think perhaps the best solution is a sandbox where we could collaborate
on the unfinished aspect of this patch, and abuse the proxy/location/dir/files
handlers into cooperating with a new schema.
If noone objects, I'll fork the sandbox for this experiment later this evening.
Re: Remove and ?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 9/18/2010 5:45 PM, Stefan Fritsch wrote:
>
> What do other people think about removing <Limit> and <LimitExcept>
> and adding mod_allowmethods from the sandbox to easily forbid some
> methods? Or would this create too much trouble when upgrading
> configurations?
I've been distracted by patches which I owe to specific users, customers
and so forth, so I haven't actually had cycles to commit the patches that
float my own boat :)
But what I have are two patches, one which rips out Limit entirely from
the httpd code, along with the method limit logic from the handful of
directives which actually supported the feature, and a second patch which
introduces Method as a section and supports all directives, just as any
other first class Location, Directory, etc.
The unfinished bit of that patch is deciding how and where the section
merge will occur. Since it's a NTP that could lead to some degree of
confusion about scoping, it really seems like that should happen every
time a per-dir merge occurs.
What I'm thinking of for the solution is to have a post-merge hook, so
that remerges can occur for any registered section provider. The whole
<Files > merge could become one consumer of this hook. That hook would,
of course, return a newly merged section or the identity of the source
dir config, if everyone declines. It's recursive, in that you could
end up with a nested Files in a location, which in turn has nested methods
which are acceptable.
Does anyone have thoughts on the best way to handle per-dir nesting?
Re: Remove and ?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 9/21/2010 5:16 PM, Igor Galić wrote:
>
> ----- "Stefan Fritsch" <sf...@sfritsch.de> wrote:
>
>> I am not a heavy DAV user. But I think most useful uses of
>> Limit/LimitExcept are already possible with the combination "Require
>> method", <RequireAny>, and <RequireAll>. See
>> http://httpd.apache.org/docs/trunk/mod/mod_authz_host.html#reqmethod
>
> Alternatively you can also use
>
> Require not method GET POST OPTIONS
All of these, including <If > tests and mod_lua magic, are all valid and
respectable solutions. The only reason that <method > interests me is
academic, in terms of nesting logic, and overrides of non-auth directives,
which <Limit> never did.
Re: Remove and ?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 9/21/2010 5:16 PM, Igor Galić wrote:
>
> ----- "Stefan Fritsch" <sf...@sfritsch.de> wrote:
>
>> On Monday 20 September 2010, Greg Stein wrote:
>>> The Limit/LimitExcept directives are very handy and important when
>>> mod_dav is being used. In fact, LimitExcept was created
>>> specifically in order to avoid listing every new method that might
>>> come along via DAV specs and such.
>>>
>>> As long as an alternative is available, then I don't care. But the
>>> functionality is very important.
>>
>> I am not a heavy DAV user. But I think most useful uses of
>> Limit/LimitExcept are already possible with the combination "Require
>> method", <RequireAny>, and <RequireAll>. See
>> http://httpd.apache.org/docs/trunk/mod/mod_authz_host.html#reqmethod
>
> Alternatively you can also use
>
> Require not method GET POST OPTIONS
Would this be a better patch here in our example config;
Index: docs/conf/extra/httpd-dav.conf.in
===================================================================
--- docs/conf/extra/httpd-dav.conf.in (revision 775681)
+++ docs/conf/extra/httpd-dav.conf.in (working copy)
@@ -28,9 +28,9 @@
# Allow universal read-access, but writes are restricted
# to the admin user.
- <LimitExcept GET POST OPTIONS>
+ <MethodExcept GET POST OPTIONS>
require user admin
- </LimitExcept>
+ </MethodExcept>
</Directory>
#
Feel free to go ahead and fix our example to the new Require API.
Re: Remove and ?
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Wednesday 22 September 2010, Igor Galić wrote:
> ----- "Stefan Fritsch" <sf...@sfritsch.de> wrote:
> > On Monday 20 September 2010, Greg Stein wrote:
> > > The Limit/LimitExcept directives are very handy and important
> > > when mod_dav is being used. In fact, LimitExcept was created
> > > specifically in order to avoid listing every new method that
> > > might come along via DAV specs and such.
> > >
> > > As long as an alternative is available, then I don't care. But
> > > the functionality is very important.
> >
> > I am not a heavy DAV user. But I think most useful uses of
> > Limit/LimitExcept are already possible with the combination
> > "Require method", <RequireAny>, and <RequireAll>. See
> > http://httpd.apache.org/docs/trunk/mod/mod_authz_host.html#reqmet
> > hod
>
> Alternatively you can also use
>
> Require not method GET POST OPTIONS
This currently has the problem that "Require not" will not allow
access by itself but return "neutral" if the condition is not met.
I hope that the beta phase will reveal if this behaviour makes sense
or should be changed. But before changing it, one would need to look
in the list archives why it was implemented this way.
Re: Remove and ?
Posted by Igor Galić <i....@brainsware.org>.
----- "Stefan Fritsch" <sf...@sfritsch.de> wrote:
> On Monday 20 September 2010, Greg Stein wrote:
> > The Limit/LimitExcept directives are very handy and important when
> > mod_dav is being used. In fact, LimitExcept was created
> > specifically in order to avoid listing every new method that might
> > come along via DAV specs and such.
> >
> > As long as an alternative is available, then I don't care. But the
> > functionality is very important.
>
> I am not a heavy DAV user. But I think most useful uses of
> Limit/LimitExcept are already possible with the combination "Require
> method", <RequireAny>, and <RequireAll>. See
> http://httpd.apache.org/docs/trunk/mod/mod_authz_host.html#reqmethod
Alternatively you can also use
Require not method GET POST OPTIONS
> If you can think of any configuration that isn't, that would be very
> interesting.
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
Re: Remove and ?
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Monday 20 September 2010, Greg Stein wrote:
> The Limit/LimitExcept directives are very handy and important when
> mod_dav is being used. In fact, LimitExcept was created
> specifically in order to avoid listing every new method that might
> come along via DAV specs and such.
>
> As long as an alternative is available, then I don't care. But the
> functionality is very important.
I am not a heavy DAV user. But I think most useful uses of
Limit/LimitExcept are already possible with the combination "Require
method", <RequireAny>, and <RequireAll>. See
http://httpd.apache.org/docs/trunk/mod/mod_authz_host.html#reqmethod
If you can think of any configuration that isn't, that would be very
interesting.
Re: Remove and ?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 9/20/2010 12:27 PM, Greg Stein wrote:
> The Limit/LimitExcept directives are *very* handy and important when
> mod_dav is being used. In fact, LimitExcept was created specifically
> in order to avoid listing every new method that might come along via
> DAV specs and such.
>
> As long as an alternative is available, then I don't care. But the
> functionality is very important.
Agreed. Although I have seen (from the dav perspective) many too many
configurations with directives other than the three, with the author's
expectation that they were triggered only for the Limit[Except] methods.
That's the idea of both the Method[Except] block and Nick's illustration
of the If block. In 2.4, we shouldn't be accepting directives that don't
actually respect the container they are placed within, and operate without
any indication that it is a misconfiguration.
The ability to control by [unknown] methods isn't going anywhere, in fact
there will be MTOWTDI reliably, out of the box :)
Re: Remove and ?
Posted by Greg Stein <gs...@gmail.com>.
The Limit/LimitExcept directives are *very* handy and important when
mod_dav is being used. In fact, LimitExcept was created specifically
in order to avoid listing every new method that might come along via
DAV specs and such.
As long as an alternative is available, then I don't care. But the
functionality is very important.
Cheers,
-g
On Sat, Sep 18, 2010 at 18:45, Stefan Fritsch <sf...@sfritsch.de> wrote:
> This is from https://issues.apache.org/bugzilla/show_bug.cgi?id=49927
>
> On Saturday 18 September 2010, bugzilla@apache.org wrote:
>> --- Comment #3 from Nick Kew <ni...@webthing.com> 2010-09-18
>> 06:38:34 EDT ---
>>
>> > No, the current documentation is correct. The semantics of
>> > Limit/LimitExcept is just insane. We should relly get rid if it
>> > in 2.4 and improve the docs for 2.2. Maybe the "unprotected"
>> > should be big, red, and blinking ;-)
>>
>> Agreed. We can even document it as superseded by
>> <If "$request-method ...">
>> having of course checked the expression parser, which probably
>> needs updating to support things like
>> "... in GET,HEAD,OPTIONS,TRACE"
>> without some nasty great OR expression.
>
> What do other people think about removing <Limit> and <LimitExcept>
> and adding mod_allowmethods from the sandbox to easily forbid some
> methods? Or would this create too much trouble when upgrading
> configurations?
>
>
> BTW, we could also add an authz provider to allow things like
>
> Require method GET,HEAD,...
>
> Though this would be slower than mod_allowmethods because authz
> providers have to parse the require line on every request.
>
Remove and ?
Posted by Stefan Fritsch <sf...@sfritsch.de>.
This is from https://issues.apache.org/bugzilla/show_bug.cgi?id=49927
On Saturday 18 September 2010, bugzilla@apache.org wrote:
> --- Comment #3 from Nick Kew <ni...@webthing.com> 2010-09-18
> 06:38:34 EDT ---
>
> > No, the current documentation is correct. The semantics of
> > Limit/LimitExcept is just insane. We should relly get rid if it
> > in 2.4 and improve the docs for 2.2. Maybe the "unprotected"
> > should be big, red, and blinking ;-)
>
> Agreed. We can even document it as superseded by
> <If "$request-method ...">
> having of course checked the expression parser, which probably
> needs updating to support things like
> "... in GET,HEAD,OPTIONS,TRACE"
> without some nasty great OR expression.
What do other people think about removing <Limit> and <LimitExcept>
and adding mod_allowmethods from the sandbox to easily forbid some
methods? Or would this create too much trouble when upgrading
configurations?
BTW, we could also add an authz provider to allow things like
Require method GET,HEAD,...
Though this would be slower than mod_allowmethods because authz
providers have to parse the require line on every request.
DO NOT REPLY [Bug 49927] Explanation of the #limit directive
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49927
--- Comment #3 from Nick Kew <ni...@webthing.com> 2010-09-18 06:38:34 EDT ---
> No, the current documentation is correct. The semantics of Limit/LimitExcept is
> just insane. We should relly get rid if it in 2.4 and improve the docs for 2.2.
> Maybe the "unprotected" should be big, red, and blinking ;-)
Agreed. We can even document it as superseded by
<If "$request-method ...">
having of course checked the expression parser, which probably needs updating
to support things like
"... in GET,HEAD,OPTIONS,TRACE"
without some nasty great OR expression.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
DO NOT REPLY [Bug 49927] Explanation of the #limit directive
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49927
Rich Bowen <rb...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|bugs@httpd.apache.org |docs@httpd.apache.org
--- Comment #4 from Rich Bowen <rb...@apache.org> 2010-10-29 11:07:27 EDT ---
Moving docs bugs to docs@httpd.a.o ownership.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org