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 18:21:40 GMT
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'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.

Chris.

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




Mime
View raw message