httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <>
Subject Re: AuthzMergeRules directive
Date Fri, 13 Jun 2008 21:03:47 GMT
>>> On 5/2/2008 at 11:54 AM, in message <>, Chris
Darroch <> wrote:
> Brad Nicholes wrote:
>> So what I am really trying to say is that intra-block logic and
>> inter-block logic as far as merging goes, are tied together.  If we
>> want to change the way that the logic of two block is merged, we
>> would also have to change the base state of each independent block.
>> It's all or nothing.  This would affect how the following block is
>> evaluated:
>> <Directory /foo>
>> require user joe
>> require user sue
>> </Directory>
>> As it currently stands, the logic when combining these two rules would
>> be OR.  If we make the change, this would also change the same
>> configuration to use AND instead.  I think we determined that this
>> logic would be more secure anyway even if it is different than 2.2.x.
>    Well, I suppose the absolutely key thing is to set the default
> AuthzMergeRules state to "Off".  Next up, I guess try changing the
> "On" merge state to AND and we'll do some thinking and testing at
> that point.
>    It does look to me like the pre-2.4 intra-block logic was OR,
> but I don't know how widely people would have depended on that
> (as in your example above).  My gut instinct is that we'll wind up
> having to replicate OR within blocks, but implement AND between
> blocks, to achieve both backwards-compatibility and good security.
>    As a first step, though, I'd suggest just making the two changes
> to the existing defaults (AuthzMergeRules Off as default, and On => AND)
> and we'll review again at that point.

I finally got around to making the switch so that the default merge rule is AND rather than
OR.  However after making the switch, it occurred to me that since the default rule is AND
now, the AuthzMergeRules default should remain ON.  Otherwise the rule inheritance won't happen
by default which would leave authentication holes in sub-directories.  I think with the default
being changed to AND, authz should be behaving as discussed on this thread.


View raw message