>>> 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
