config/1941: AllowOverride ignored in and

[Mike Brudenell <pm...@york.ac.uk>]

>Number:         1941
>Category:       config
>Synopsis:       AllowOverride ignored in <Directory ~ pattern> and <DirectoryMatch pattern>
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Fri Mar 13 05:10:00 PST 1998
>Last-Modified:
>Originator:     pmb1@york.ac.uk
>Organization:
apache
>Release:        1.3b5
>Environment:
pump1> uname -a
SunOS pump1.york.ac.uk 5.5.1 Generic_103640-08 sun4u sparc SUNW,Ultra-2

pump1> which cc
  /opt/SUNWspro/bin/cc
pump1> cc -V
cc: SC4.0 18 Oct 1995 C 4.0
>Description:
The AllowOverride directive is apparently being ignored if used within a
<Directory> block that uses a regular expression "~" pattern or in a
<DirectoryMatch> block.

It IS honoured within <Directory> blocks using an exact name or a glob-tyle "*"
pattern.

This prevents the AllowOverride settings to be changed for directories selected
by regular expression so as, for example, to allow them to use a .htaccess
file to override access rights.
>How-To-Repeat:
First set up access controls to your http document root as usual.  I will be
assuming this is /htdocs, and that URLs are relative to this.  Turn off
AllowOverride by default for the entire filestore tree:

<Directory />
    Allow from all
    AllowOverride None
</Directory>

The aim is to set up a mechanism whereby any directory whose name ends ".ltd"
is NOT accessible UNLESS it contains an .htaccess file specifically granting
access.

First set up a block denying access to /htdocs/.../*.ltd directories and test:

<Directory ~ "^/htdocs/.*\.ltd">
    Deny from all
</Directory>

Attempting to access a directory such as /physics/secret.ltd is correctly
denied access.

Now set up an .htaccess in the /htdocs/physics/secret.ltd directory to allow
access:

<FilesMatch *>
    Allow from all
</FilesMatch>

and then modify the server's access block for ".ltd" directories to allow
the .htaccess file to override the Limit category of directives.  The block
then becomes:

<Directory ~ "^/htdocs/.*\.ltd">
    Deny from all
    AllowOverride Limit
</Directory>

Test this configuration by requesting the /physics/secret.ltd/ URL.
The request STILL FAILS, showing that the "Deny from all" in the server
configuration is NOT being overridden by the directories .htaccess file.

Now change the block to name the directory explicitly rather than using a
regular expression:

<Directory "/htdocs/physics/secret.ltd">
    Deny from all
    AllowOverride Limit
</Directory>

When tested the request now SUCCEEDS, showing the .htaccess file IS now
correctly overriding the configuration file's "Deny form all" default.

To confirm that this difference is not just down to a bad pattern, change this
latest block to use an equivalent, simple-minded, regular expression consisting
of exactly the directory name (ie, no wild-cards):

<Directory ~ "/htdocs/physics/secret\.ltd">
    Deny from all
    AllowOverride Limit
</Directory>

Requesting the /physics/secret.ltd URL now FAILS, even though this "pattern" is
functionally equivalent to the preceding exactly specified, non-expression,
name.

In Summary:

*  The AllowOverride directive is apparently ignored for <Directory> blocks
   making use of "~" regular expressions or <DirectoryMatch> blocks (even when
   no wild-cards are used in the pattern).

*  The AllowOverride directive IS apparently honoured for <Directory> directives
   using either an exact name or a glob-type "*" pattern.

*  Not all directive are affected: in the above examples changing the "Deny from
   all" to "Allow from all" always allows access.  This implies that the "Deny"
   and "Allow" directives within <Directory> + regular expression blocks are
   being seen and honoured.
   Therefore the problem seems to lie with something peculiar to the
   AllowOverride directive.

If you have problems reproducing the problem or need further information please
feel free to contact me.
>Fix:
I'm sorry, but I don't have any suggestions for a fix
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include <ap...@Apache.Org> in the Cc line ]
[and leave the subject line UNCHANGED.  This is not done]
[automatically because of the potential for mail loops. ]