httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Poirier" <>
Subject Re: AuthzMergeRules blocks everything in default configuration
Date Mon, 06 Oct 2008 13:34:50 GMT
On Tue, 23 Sep 2008 11:05:45 -0700, "Chris Darroch"
<> said:
> Dan Poirier wrote:
> > I read through some previous discussion of the authz inheritance
> > behavior, but it doesn't seem to have considered the effect of having
> > "Require all denied" at the top level, which is overriding everything
> > else by default even when other sections specify other permissions.

[omitted some history]
>    Let's say you've got two authz configs, A and B, and A is considered
> before B (maybe A is in <Directory /> and B is in <Directory /foo> for
> a given request (e.g., for /foo/bar).
>    Previously [in trunk] the default merge rule was "OR", i.e., A ||
> B.  Thus in the case where A allowed access and B didn't, you'd be
> let in despite B's local authz denying you access.  That would, I
> thought, have created a lot of unexpected security holes for people
> who upgraded from 2.2, where B's local authz was the only authority.


>    Brad Nicholes changed that a few months ago so that the default
> rule should be "AND", i.e., A && B.  Thus in the case above, you'd
> be denied access because of B's config.
>    This closes off the worst security problems, I think.  As you note,
> though, it can produce situations where A's config denies you access
> and so B's is just ignored, even if B wants to let you have access.
> You can set AuthzMergeRules Off for B, but also as you note you'd have to
> set it everywhere.  And since it's value isn't "inherited", if
> A, B, and C all apply to the request, then turning it Off for B
> means you'll still get B && C applied, not just C.
>    We can obviously change the example configs so as to make
> the <Directory /> setting have "Require all granted".  However, I
> think we'll find that fair numbers of people get themselves into
> this situation -- by naively upgrading using 2.2 configs, assuming
> things work the 2.2 way (B isn't affected by A), assuming AuthzMergeRules
> values are "inherited", etc.  

I don't think we really want to change <Directory /> to "Require
all granted", do we?  Wouldn't that open up the entire system by

>    Hence my feeling that the default should be Off (to be closer
> to 2.2 behaviour), and when explicitly On, the rule that's applied
> should be AND -- as is now true, thanks to Brad!
>    One further thought of mine from ages ago was that On (which
> currently means AND) could be replaced by two non-default options,
> And and Or (or SastifyAll and SastifyOne, respectively).  Then
> the administrator would have full control over the inter-block
> merge rule, similar to the control they have in trunk over the
> intra-block rules via <SastifyAll> and <SastifyOne>.

I like the idea of replacing ON with AND and OR.  It would not
only provide more control, but make it explicit what kind of merging
was going to happen.

I have mixed thoughts about changing the default to OFF.  

Cons: That would mean every container directive would have to specify
some sort of access control (or at least AuthzMergeRules AND) or it'd
be wide open, right?

Pros: On the other hand, that's the behavior in 2.2, and changing it
would surely cause confusion for people trying to migrate to the new
behavior.  As you point out, it's also confusing to put configuration
in B that ought to grant access, and find that access is still denied
due to a setting in A.

One other idea occurs to me.  Would it seem more intuitive if a
context that had no authz directives inherited the settings from its
predecessor, but as soon you added authz directives, it behaved as if
you were starting from scratch?  (As if you'd included AuthzMergeRules
Off.  You could always add AuthzMergeRules AND if you wanted that
behavior.)  Or would it just be more confusing?  I guess you'd still
have to go through the default configuration files adding "Require
all granted" or "AuthzMergeRules Off" everywhere in order to give
access to anything, since otherwise they'd still inherit from the
top-level's not granting any access.

>    Thoughts?  I apologize profusely for having so little time to
> devote to actual useful coding at the moment.

I'd like to hear what others think.  Can the current behavior be
improved, and if so, how?


View raw message