httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: AuthzMergeRules directive
Date Mon, 14 Apr 2008 18:43:44 GMT
>>> On 4/14/2008 at 12:21 PM, in message <4803A0B4.6070005@pearsoncmg.com>,
Chris
Darroch <chrisd@pearsoncmg.com> 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
 


Mime
View raw message