Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of poirier@pobox.com designates
 207.106.133.19 as permitted sender)
Message-ID: <48D7D3F7.1080804@pobox.com>
Date: Mon, 22 Sep 2008 13:20:55 -0400
From: Dan Poirier <poirier@pobox.com>
User-Agent: Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: AuthzMergeRules blocks everything in default configuration
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I hate to re-open this can of worms, but...

Unless I'm missing something, in trunk right now, uncommenting includes 
for the examples like "extra/httpd-manual.conf" does not result in being 
able to serve the documentation pages.

In the main config file:

<Directory />
  Require all denied
</Directory>

blocks all access, and that's inherited by every other <Directory> or
<Location> in the configuration, since AuthzMergeRules defaults to On.

To make this work, one would have to add AuthzMergeRules Off to every 
other <Directory> or <Location> in the configuration that isn't a subset 
of another one
that already has it.

Doing that makes me wonder what's the point of having it, if we have to 
turn it
off in almost every case to actually serve pages.

Or would it make sense to add AuthzMergeRules Off to <Directory />?  
Would that
make the rest of the permissions kind of stand alone?  I guess then 
you'd have
to add AuthzMergeRules On to any of them whose permissions you wanted
inherited by even lower level sections.

I read through some previous discussion of the authz inheritance 
behavior, but
it doesn't seem to have considered the effect of having "Require all 
denied" at
the top level, which is overriding everything else by default even when 
other
sections specify other permissions.

Dan