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 Tue, 23 Sep 2008 18:05:45 GMT
Dan Poirier wrote:

> Unless I'm missing something, in trunk right now, uncommenting includes 
> for the examples like "extra/httpd-manual.conf" does not result in being 
> able to serve the documentation pages.
> 
> In the main config file:
> 
> <Directory />
>   Require all denied
> </Directory>
> 
> blocks all access, and that's inherited by every other <Directory> or
> <Location> in the configuration, since AuthzMergeRules defaults to On.

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


   A while back I wrote the following and haven't had a moment to
catch up and do the testing I hoped to do.  However, yes, in the
abstract I think we're talking about the same problem:

>>    It's been a while since I thought about this stuff, but I think
>> the reason I was keen to make the AuthzMergeRules default off was that
>> it more closely emulated the pre-2.4 behaviour, so that people wouldn't
>> be surprised to discover their 2.2 configurations weren't working
>> as expected.  Combined with a default OR rule that might have led, I
>> thought, to unanticipated security holes -- users given access to a
>> subdir with its own authz config because the OR with the parent dir
>> short-circuited the subdir's authz.  Using AND as the default rule will
>> at a minimum close off that problem.
>> 
>>     My hunch (absent any testing; sorry!) is that a default AND will
>> mean such subdirs are sometimes just not available after an upgrade to 2.4
>> (assuming no authz config changes are made by someone who doesn't read
>> the release notes) because users won't have access to both the parent dir
>> and the subdir.  In 2.2, they'd be authorized against just the subdir's
>> config; here, they'll need to pass the parent's too.  (I think.)  Anyway,
>> I'll try to work in some testing in the next week or two.


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

   In 2.2, IIRC, only B would be applied to your request.  With trunk,
A and B are at least considered.  How depends on the "merge rule"
in effect, which is controlled by AuthzMergeRules.

   Note that that directive only takes effect locally for a particular
config block.  Its value doesn't get "inherited" in the sense that if B
turns it Off (so A is ignored for a request for which A and B match),
then if config C matches as well (say, <Directory /foo/bar>) but doesn't
specify a merge rule, the default merge rule is still used to
merge B and C.  The Off state merely means that B isn't merged with
any predecessor configs (i.e., A).


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

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

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

Chris.

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


Mime
View raw message