httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <chr...@pearsoncmg.com>
Subject Re: AuthzMergeRules directive
Date Mon, 14 Apr 2008 21:29:38 GMT
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.

   I take your point about complexity, but on the other hand,
these aren't alternate logic directives -- they're additional.
The logic specified above for /www/pages/private would be:

( Require ip 10.10.0.1
  &&
  Require ldap-group sales
  &&
  ( Require ldap-group ne-sales
    ||
    Require ldap-group sw-sales))
||					<- AuthzMergeRules SastifyOne
( Require ldap-group marketing
  &&
  Require ldap-group alt-marketing)

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

   Granted, the above example is complex and maybe non-intuitive,
but most people aren't going to attempt or need such a large set
of authz directives.  For those who really do, there are surely
going to be cases where AND'ing block is useful while OR'ing is
not at all (since OR'ing tends to short-circuit the configurations
deeper down the document tree, which seems unlikely to be what people
will mostly want).

   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:

<Directory /www/private>
    Require ip 10.10.0.1
</Directory>
<Directory /www/private/sales>
    ## must come from 10.10.0.1
    AuthzMergeRules SatisfyAll

    <SatisfyAll>
        Require ldap-group sales
        <SatisfyOne>
            Require ldap-group ne-sales
            Require ldap-group sw-sales
        </SatisfyOne>
    </SatisfyAll>
</Directory>
<Directory /www/private/sales/admin>
    ## must come from 10.10.0.1, belong to "sales", and also
    ## belong to one of "ne-sales" or "sw-sales"

    AuthzMergeRules SatisfyAll
    <SatisfyAll>
        Require ldap-group admin
        Require ldap-group sales-admin
    </SatisfyAll>
</Directory>

   Perhaps others have opinions on this stuff?  Basically my principal
concern is that the default AuthzMergeRules setting must be "Off".
Beyond that, I can live any other choices.

   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.

Chris.

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


Mime
View raw message