>>> On 4/14/2008 at 3:29 PM, in message <[EMAIL PROTECTED]>, Chris Darroch <[EMAIL PROTECTED]> wrote: > Brad Nicholes wrote: > >> This is where it starts to go wrong for me. Where it gets confusing >> for somebody who is trying to figure out what the configuration >> is doing is: >> >> <Directory /www/pages> >> <SatisfyAll> >> Require ip 10.10.0.1 >> Require ldap-group sales >> <SatisfyOne> >> Require ldap-group ne-sales >> Require ldap-group sw-sales >> </SatisfyOne> >> </SatisfyAll> >> </Directory> >> >> <Directory /www/pages/private> >> AuthzMergeRules SatisfyOne >> <SatisfyAll> >> Require ldap-group marketing >> Require ldap-group alt-marketing >> </SatisfyAll> >> </Directory> >> >> Now I have to reconcile the logic of the parent with the logic of >> both the AuthzMergeRules and the <SatisfyAll> tag. Even though it >> might not always look like the cleanest configuration, I think it >> will be less confusing if the logic rules were confined to >> the <SatisfyAll> and <SatisfyOne> tags rather than introducing >> alternate logic directives. >
[snip] > If you'd like to stick to just "Off" (my proposed default for > AuthzMergeRules) and "On", perhaps AND should be the logic implemented > by "On"? Consider the following, where AND'ing helps tighten > security as you go down the tree: > [snip] > Personally, I'm gradually coming around to the feeling that AND is > more useful/secure than OR when merging per-dir blocks, and possibly > even within a single per-dir block (although that's another conversation), > and so should either be an option to AuthzMergeRules or the action > implemented by "On" if there are only two states. > > The reason I say it might make sense to AND authz requirements > within a block is that it "reads" a little more naturally. Consider > the following, which suggests to me that I need a shirt and shoes > to be served, not one or the other: > > <Directory /www/service> > Require shirt on > Require shoes on > </Directory> > > At rate rate, thanks for hashing through all my scattershot ideas > on this stuff. > 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. Brad
