On Tue, 23 Sep 2008 11:05:45 -0700, "Chris Darroch" <[EMAIL PROTECTED]> 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. Agreed. > 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 default? > 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? Dan
