Return-Path: 
 <dev-return-61151-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org>
Delivered-To: apmail-httpd-dev-archive@www.apache.org
Received: (qmail 15363 invoked from network); 29 Apr 2008 20:27:58 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 29 Apr 2008 20:27:58 -0000
Received: (qmail 3874 invoked by uid 500); 29 Apr 2008 20:27:56 -0000
Delivered-To: apmail-httpd-dev-archive@httpd.apache.org
Received: (qmail 3846 invoked by uid 500); 29 Apr 2008 20:27:56 -0000
Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
list-help: <mailto:dev-help@httpd.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@httpd.apache.org>
List-Post: <mailto:dev@httpd.apache.org>
List-Id: <dev.httpd.apache.org>
Delivered-To: mailing list dev@httpd.apache.org
Received: (qmail 3835 invoked by uid 99); 29 Apr 2008 20:27:56 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Apr 2008 13:27:56 -0700
X-ASF-Spam-Status: No, hits=-4.0 required=10.0
	tests=RCVD_IN_DNSWL_MED,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [137.65.248.127] (HELO lucius.provo.novell.com)
 (137.65.248.127)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Apr 2008 20:27:12 +0000
Received: from INET-PRV1-MTA by lucius.provo.novell.com
	with Novell_GroupWise; Tue, 29 Apr 2008 14:27:24 -0600
Message-Id: <481730C3.6720.00AC.0@novell.com>
X-Mailer: Novell GroupWise Internet Agent 7.0.3 
Date: Tue, 29 Apr 2008 14:27:21 -0600
From: "Brad Nicholes" <BNICHOLES@novell.com>
To: <dev@httpd.apache.org>
Subject: Re: AuthzMergeRules directive
References: <C417A5C6.AD05D%Brian.Akins@turner.com>
 <47F3FFA6.8090904@rowe-clan.net> <47F40129.5090205@rowe-clan.net>
 <47F40394.90407@rowe-clan.net>
 <43e40e000804030113s18451aaes1e0c4b6b94d6a9d3@mail.gmail.com>
 <BAD7EF2A-B85E-4D56-96AA-36A97E65E218@jaguNET.com>
 <99EA83DCDE961346AFA9B5EC33FEC08B857A91@VF-MBX11.internal.vodafone.com>
 <47F4EE19.3080903@rowe-clan.net> <47F513B8.5060202@pearsoncmg.com>
 <47F5D6B7.9060907@rowe-clan.net> <47F6675A.2050105@pearsoncmg.com>
 <47F647BE.6720.00AC.0@novell.com> <47F6ACBE.8000305@pearsoncmg.com>
 <47FA5EE4.6720.00AC.0@novell.com> <47FBA057.3000008@pearsoncmg.com>
 <47FB798D.6720.00AC.0@novell.com> <47FBE9A2.7070201@pearsoncmg.com>
 <47FCF810.90804@pearsoncmg.com> <47FE430E.6720.00AC.0@novell.com>
 <4803A0B4.6070005@pearsoncmg.com> <480351F7.6720.00AC.0@novell.com>
 <4803CCC2.8080108@pearsoncmg.com> <48060020.6720.00AC.0@novell.com>
 <4808B5D8.3010803@pearsoncmg.com>
In-Reply-To: <4808B5D8.3010803@pearsoncmg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Virus-Checked: Checked by ClamAV on apache.org

>>> On 4/18/2008 at 8:53 AM, in message <4808B5D8.3010803@pearsoncmg.com>, =
Chris
Darroch <chrisd@pearsoncmg.com> wrote:
> Brad Nicholes wrote:
>=20
>> 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.
>=20
>    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,
>=20
> 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_ON=
E (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