>>> On 4/14/2008 at 12:21 PM, in message <[EMAIL PROTECTED]>, Chris
Darroch <[EMAIL PROTECTED]> wrote:
> Brad Nicholes wrote:
>
>> I'm not real excited about adding a new authz directive. Authn and
>> authz are already very complex and adding a new directive to the mix will
>> just help to confuse people even more.
>
> That's a good point. Mostly the idea of an Accept replacement for
> Require came up as a way to distinguish pre-2.4 and 2.4 per-dir authz,
> and in case there were any "Require foo" directives which had slightly
> different meanings in the two contexts and which might therefore trip
> people up. If we can do without it, all the better.
>
>
>> I am OK with this one except for the reason that I mentioned before.
>> By allowing authz to be inherited even when AuthzMergeRules is OFF is
>> kind of a conflict. In other words, since AuthzMergeRules OFF implies
>> an AND, 1 AND 0 should be 0 or no authz rather than inherited authz.
>> However I could buy into this if it seems to make more intuitive sense
>> to the user.
>
> Well, I may be missing something, but what I envisioned was that
> AuthzMergeRules had three options: "Off" (i.e., inherited until overridden,
> the pre-2.4 default), "SatisfyOne", and "SatisfyAll". That would give
> administrators full control over how they wanted authz in different
> per-dir blocks to be merged.
>
> It seems to me we have three basic possibilities when it comes to
> merging authz across per-dir blocks, and the most common authz case
> to consider is going to be where security gets tighter as you move down
> the document tree. Imagine something like the following in a pre-2.4
> configuration, where "admin" is not a member of "team":
>
> <Directory /htdocs>
> ## full access
> </Directory>
> <Directory /htdocs/team>
> ## anyone in "team" has access
> Require group team
> </Directory>
> <Directory /htdocs/team/admin>
> ## only "admin" user has access
> Require user admin
> </Directory>
>
>
> 1) The first option for 2.4 merging is to use OR logic (the current
> default in trunk). This leads to anyone in "team" having access to
> /htdocs/team/admin, I believe. I think I'd have to vote -1 against
> this, because it will lead to lots of previously secure configurations
> becoming insecure. Plus it would seem to increase the required
> number of directives (since you have to add "AuthzMergeRules Off"
> in each sub-<Directory>) to achieve what seems to me to be a typical
> configuration, i.e., increasing security as you go down the tree.
>
> 2) Another option might be to use AND logic. In this case, if I'm
> applying the logic correctly, no one would be able to access
> /htdocs/team/admin given the configuration above in a 2.4 context
> (since "admin" isn't in "team"). While more secure, this also seems
> counter-intuitive to me. Maybe -0.5?
>
> 3) Finally there's the pre-2.4 logic of overriding all previous authz.
> This would seem to be the most preferable option, since it ensures
> many pre-2.4 configurations will continue to work as expected, and
> I think also reduces configuration verbosity in typical cases.
>
>
> You were concerned, I think, about more complex configurations
> like this:
>
>>> <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>
>>> Require ldap-group marketing
>>> </Directory>
>
> I would suggest that the default pre-2.4 logic of overriding previous
> authz when any authz is defined in a per-dir block is still reasonable as
> a default. Thus, only those in "marketing" have access to
> /www/pages/private, and they can access it from other addresses than
> 10.10.0.1. Even if this isn't what is desired, it's clear enough that
> an administrator can figure out what's going on and why the configuration
> isn't achieving the desired result.
>
I'm OK with it up to this point.
> I'd propose giving the administrator the choice of both alternatives
> to the default logic. Instead of simply offering "AuthzMergeRules On",
> there would be two alternatives to the default "Off" condition. These
> would be "AuthzMergeRules SatisfyOne" (the OR logic) and
> "AuthzMergeRules SatisfyAll" (the AND logic).
>
> We might offer "Or" and "And" as synonyms for "SatisfyOne" and
> "SatisfyAll", respectively.
>
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. At least with AuthzMergeRules being ON
or OFF, the only thing I need to know is if I am merging with the parent or
not. All of the logic rules just flow from there.
Brad
