Brad Nicholes wrote:
<Directory /www/pages>
Reject ip 127.0.0.1 //Or any other Require directive
</Directory>
<Directory /www/pages/whatever>
...
</Directory>
Since the /www/pages/whatever directory did not specify any authz,
what should happen? If the AuthzMergeRules is OFF then what is the
authz for /www/pages/whatever? I'm not sure that 'all granted' is
correct but then neither is 'all denied'. Since the AuthzMergeRules
is OFF then merging the authz would be counter intuitive.
If AuthzMergeRules is ON then 127.0.0.1 is rejected and all
others are allowed. I guess the thinking was that leaving the
default ON would leave fewer unknowns however in some instances may
not be as intuitive.
Well, again referring to my intuition based on configuring 2.2
and prior servers, I would expect the /www/pages authz to cover
everything under /www/pages (including /www/pages/whatever) unless
I define other authz rules -- at which point, the corresponding authz
slate is wiped clean for that subdirectory, and my local authz
directives take effect. (Not all authz directives, mind you, just
those which I'm overriding.)
So I can do something like:
<Directory /www/pages>
Require valid-user
</Directory>
<Directory /www/pages/images>
## still protected
Dav filesystem
</Directory>
<Directory /www/pages/private>
Require user admin
</Directory>
One key to this behaviour, IIRC, is that all of the stock authz
modules in 2.2 use the default merge_dir_config rules; that is,
none of them define their own merge function and all just say:
NULL, /* dir merger --- default is to override */
Then the ap_merge_per_dir_configs() logic which gets applied
when merging their per-directory configurations is to cause the
ancestor's configuration to be inherited, unless there's a new
per-directory configuration for the same module.
The Require directive is, again IIRC, handled in the core
per-directory configuration, and the logic in merge_core_dir_configs()
is similar: duplicate the ancestor's configuration, and then
override the inherited Require directives if there's a Require
directive in the new per-directory configuration:
if (new->ap_requires) {
conf->ap_requires = new->ap_requires;
}
So I think the result is that each authz directive gets inherited
down through the directory configurations, until something overrides
it, at which point everything to do with that directive is started
fresh. It's a relatively space-efficient configuration style,
actually, because you only need to put in an authz directive if you're
changing something from what's inherited.
I hope I've described the existing situation accurately; at any rate,
it seems to me to be a good way to structure the 2.4 authz merge rules.
It would mean you mostly didn't need to specify AuthzMergeRules (saves
typing and errors) and things are protected down through the directory
hierarchy by default (also good) unless you specifically include a
new authz directive, at which point that takes effect and is inherited
downwards. So the default merge logic would be, I guess, neither AND
nor OR but inherit-until-overridden.
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
