Re: AuthzMergeRules directive

[Chris Darroch]

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.

  For my part I hope to deal with a parallel, unrelated, and hopefully
uncontroversial set of authn/z edits once SVN returns, namely changing all
the hard-coded "0" provider versions to use AUTHN/Z_PROVIDER_VERSION macros.
That's a simple first step toward the work outlined in this thread:

[EMAIL PROTECTED]

  Thanks again,

Chris.

--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B