[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-httpd-dev
Subject:    Re: AuthzMergeRules directive
From:       "Brad Nicholes" <BNICHOLES () novell ! com>
Date:       2008-04-29 20:27:21
Message-ID: 481730C3.6720.00AC.0 () novell ! com
[Download RAW message or body]

> > > On 4/18/2008 at 8:53 AM, in message <4808B5D8.3010803@pearsoncmg.com>, Chris
Darroch <chrisd@pearsoncmg.com> 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


[prev in list] [next in list] [prev in thread] [next in thread]