>>> On 4/8/2008 at 10:41 AM, in message <[EMAIL PROTECTED]>, Chris
Darroch <[EMAIL PROTECTED]> wrote:
> 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.
Your assumptions about how the 2.2 per-dir merging is correct. Unfortunately
the same concepts no longer apply to 2.4. The reason why is this:
<Directory /www/pages>
<SatisfyAll>
Require ip 10.10.0.1
Require ldap-group sales
<SatisfyOne>
Require ldap-group ne-sales
Require ldap-group sw-sales
</SatisfyOne>
</SatisfyAll>
</Directory>
<Directory /www/pages/images>
## still protected
Dav filesystem
</Directory>
<Directory /www/pages/private>
Require ldap-group marketing
</Directory>
Which ldap-group is overridden vs merged? Since the 2.2 authz had no concept
of logic and was simply a list of require statements, it was very easy to add
to the list or override an entry in the list. This is no longer the case. The
require statements have to be merged according to some type of logic rules.
Your suggestion would work if /www/pages/private simply reset and applied only
the require statements it found in its own directory block (ie. AuthzMergeRules
OFF), but picking the inherited logic apart and trying to rework it, won't
really work.
BTW, one of the main reasons why the logic operators were added to authz was to
solve the problem that existed in 2.2. The problem was that if multiple
require statements appeared in a single directory block or in a hierarchy, you
never really knew in which order they were actually applied. Basically it came
down to the order in which the authz modules happen to have been loaded. By
applying the authz through logical operators, it replaced the simple array of
entries with a logic tree, which is why the API ap_requires() no longer exists.
It also got rid of all of the AuthzXXXAuthoritative directives which were
confusing.
Brad
