>>> On 4/18/2008 at 8:53 AM, in message <[EMAIL PROTECTED]>, Chris
Darroch <[EMAIL PROTECTED]> wrote:
> Brad Nicholes wrote:
> 
>> I could go along with switching the default merging rule from OR to AND,
>> even within a dir block.  The reason why it is OR today was basically
>> for backward compatibility.  Since there really wasn't any kind of logic
>> before, OR was just the default.  If we switch to AND as being the default
>> within a dir block, it may break some existing configurations.
>> However I also think that AND is a safer merging rule going forward.
> 
>    If we just switch the AuthzMergeRules default state to Off, and make
> On mean AND, that would be a great start.  Then maybe we can revisit
> and take a look at what breaks if the within-block merging is AND too;
> if it breaks too much stuff, maybe it needs to stay OR.  Right now
> I can't say I have an informed opinion on that.  Thanks again for working
> through this stuff,
> 
> Chris.

After re-examining the code, the above suggestion is much easier said than 
done.  The reason why is because base <Directory> logic starts from the 
AUTHZ_REQSTATE_ONE (OR) state.  So if you have two <Directory> blocks, their 
respective per-dir structures are storing their authz logic as it was evaluated 
during configuration time.  Then when the two <Directory> blocks are merged, 
they are merged according to current state.  In other words, the following 
<Directory> block would be merged using OR:

<Directory /foo>

require user joe
</Directory>

<Directory /foo/bar>

authzmergerules on
require user sue
</Directory>

The reason why is because when the <Directory> blocks were first evaluated 
independently, the starting state was AUTHZ_REQSTATE_ONE.  However in the 
following example the two <Directory> block will be merge with AND:

<Directory /foo>

require user joe
</Directory>

<Directory /foo/bar>

authzmergerules on
<satisfyall>
require user sue
</satisfyall>
</Directory>

The reason why AND is used in this situation is because the <satisfyall> block 
in the subdirectory changed its starting state from AUTHZ_REQSTATE_ONE (OR) to 
AUTHZ_REQSTATE_ALL (AND).  There isn't any way to insert a different merging 
operator.  It is always the sub-directory that determines how it will be merged 
into its parent.

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.

thoughts?

Brad

Reply via email to