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 blocks everything in default configuration
Date Thu, 30 Oct 2008 02:35:51 GMT
Eric Covener wrote:

> I tend to prefer something closer to the old name, especially with the
> Satisfy containers being optional.  IOTW the "sections" here may not
> be something explicit the user can look back to.

   (Maybe IOW, "in other words"?  :-)

   They should be: since <Directory> and friends all function as
<SatisfyAll>, everything is always a section of some type.  I could
live with SatisfyOnMerge or something similar, but I'd like "Satisfy"
in there somewhere to clarify the relationship with both the legacy
Satisfy and the new <Satisfy*> blocks.

>>     <Directory /foo>
>>         Require group shirt
>>         Require group shoes
>>     </Directory>
> 
> More common migration breakage might be using two different authz
> providers there.

   Yes, and in that case, adding a <SatisfyAny> would be needed.
Or, changing the default, which is simple.  I'm inclined to commit
as written, and if it looks like this is a sticking point, change it.
That should be trivial, since SatisfySections Any creates exactly
the same thing (during a per-dir merge), so the code paths are
all tested already.

> When do we need the negative satisfy containers? I'm having a hard
> time with this one, especially with how negating Require/Reject are
> interpreted inside -- it almost seems like the containers should be
> dictating the verbs and you should just have some more agnostic
> match-type operator with the authz providers.

   I suppose the most likely case might be something like:

<Directory /humans_and_friendlies_only>
  Require valid-user
  <SatisfyNotAll>
    Require group alien
    <SatisfyAny>
      Require group hostile
      Require group neutral
      Require group noninterventionist
    </SatisfyAny>
  </SatisfyNotAll>
</Directory>

so "aliens" are OK, unless they're in one or more of a set of
other groups.  Presumably you can't just say "Reject group alien"
at the top level because some aliens are OK, nor can you say
"Reject group hostile" at the top level, because some hostiles
are human.  Probably makes the most sense with complex LDAP setups
where people belong to lots of overlapping categories.

   I think negated sections are pretty clear and have some utility;
at a minimum, providing the ability to negate a single match
(i.e., Reject) but no equivalent negation operator at a higher level
makes for some odd constructions which can be more clearly expressed
with higher-level negation.  It's the equivalent of negated
parenthetical constructions in logical expressions, like !(A && B).

   As you note, it's a little counter-intuitive to be using Require/Reject
in these locations -- something like Match and NotMatch might make
everything clearer.  I'm happy to consider such a thing; I think I'll
get the commit in first and then we can adjust further.

   The main reason to keep Require, of course, is backward compatibility.
But we could set that up to work like Match, say, and throw an error
unless it's used in a "naked" context (outside of any <Satisfy*>).
That would be easy, and then for configurations with <Satisfy*> blocks,
one would use Match/NotMatch inside of them.

Chris.

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


Mime
View raw message