Brad Nicholes wrote:
So here was the thinking behind it when AuthzMergeRules was introduced.
Maybe there is still a bug here that needs to be addressed.
http://mail-archives.apache.org/mod_mbox/httpd-dev/200607.mbox/[EMAIL PROTECTED]
http://mail-archives.apache.org/mod_mbox/httpd-dev/200607.mbox/[EMAIL PROTECTED]
I'm not sure it's a bug per se, but rather, an unexpected break from
the intuition developed by administrators used to configuring 2.2.x and
prior versions about how authorization cascades through configuration
blocks. I may be wrong about this, but here's how I'd expect the
example from your second thread to work. The example is:
<Directory /www/pages>
Reject ip 127.0.0.1
</Directory>
<Directory /www/pages/secure>
Authtype Basic
...
<SatisfyAll>
Require valid-user
Reject user joe
</SatisfyAll>
</Directory>
My hunch is that prior to 2.2, the fundamental logic when merging
authz rules across blocks was neither AND nor OR, but "reset".
That is, it relies on the configuration walks to find the authz
directives in the most closely relevant block. Those directives
are then applied; what appeared in less relevant blocks is ignored.
I haven't looked closely at the logic, but that's what seems to happen
if you've got something like:
<Directory /htdocs>
Require valid-user
</Directory>
<Directory /htdocs/admin>
Require user admin
</Directory>
So in your example, my "configuration intuition" suggest that only
what appears in the <Directory /www/pages/secure> block applies to
anything under /www/pages/secure, and that the "Reject ip 127.0.0.1"
would just not applied at all to these URIs. So I'd expect that
to access /www/pages/secure I'd need to be any valid user except "joe";
whether I was connecting from 127.0.0.1 wouldn't matter.
Now, within a block, having OR be the default merge logic would
seem to make sense; if you want AND, you need <SatisfyAll>. So:
<Directory /www/pages/secure>
Require user betty
Require user joe
</Directory>
means "betty" and "joe" alone have access, regardless of what applied
to /www/pages. But if the following is also configured, then a "reset"
rule across blocks would mean that it does what one expects; "betty"
and "joe" would be rejected along with everyone else when attempting
to access URIs under /www/pages/secure/really.
<Directory /www/pages/secure/really>
Require all denied
</Directory>
This would presumably work identically:
<Directory /www/pages/secure/really>
Reject all granted
</Directory>
Anyway, that's a bit of a shot in the dark. Hope it helps. Thanks,
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
