>Number: 1544
>Category: documentation
>Synopsis: mod_access.html appears to have incorrect/contradictory
>examples for allow/deny/order
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: apache
>State: open
>Class: doc-bug
>Submitter-Id: apache
>Arrival-Date: Wed Dec 10 13:30:00 PST 1997
>Last-Modified:
>Originator: [EMAIL PROTECTED]
>Organization:
apache
>Release: 1.2.0, 1.3
>Environment:
any
>Description:
Of the three examples in the mod_access documentation (both in the 1.20 release
and at http://www.apache.org/docs/mod/mod_access.html), the first two appear to
assume that allow/deny directives work on the "first-match" model (i.e. that
the first allow or deny directive which matches is the one which determines
whether access is allowed), when in fact, as the final (correct) example notes,
"in all cases every allow and deny statement is evaluated, there is no
'short-circuiting.'"
The example in the documentation for the "allow" directive reads:
BrowserMatch ^KnockKnock/2.0 let_me_in
<Directory /docroot>
order allow,deny
allow from env=let_me_in
deny from all
</Directory>
Since "deny" is processed after "allow," the "deny from all" directive seems to
override any connections which would be permitted by the
"allow from env=let_me_in" directive.
Likewise, the example in the documentation for "deny" reads:
BrowserMatch ^BadRobot/0.9 go_away
<Directory /docroot>
order deny,allow
deny from env=go_away
allow from all
</Directory>
This also appears to override "deny from env=go_away" with "allow from all."
The final example, in the "order" section, appears to be correct, making the
default to deny, then permitting specific exceptions:
order deny,allow
deny from all
allow from .ncsa.uiuc.edu
(It may be worthwhile to include a more explicit explanation of the allow/deny
mechanism in the documentation, especially given that many readers may be
familiar with Wietse Venema's "tcpwrapper"/"tcpd" package, which uses a similar
syntax BUT uses the short-circuit semantics.)
>How-To-Repeat:
See http://www.apache.org/docs/mod/mod_access.html (as at 10 December 1997).
>Fix:
Assuming I haven't misunderstood the situation:
- in the first example, change "order allow,deny" to "order deny,allow",
and reverse the order of the "allow" and "deny" lines (for clarity).
- likewise, in the second example, change "order deny,allow" to "order
allow,deny", and exchange the "deny" and "allow" lines.
- include a description of which connections each example will allow,
and why.
Note that exchanging the "allow" and "deny" lines isn't necessary from a
semantic standpoint--the "order" directive controls what order they're processed
in--but doing so will make it much clearer what's going on.
%0
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include <[EMAIL PROTECTED]> in the Cc line ]
[and leave the subject line UNCHANGED. This is not done]
[automatically because of the potential for mail loops. ]
