>>> On 4/4/2008 at 4:33 PM, in message <[EMAIL PROTECTED]>, Chris Darroch <[EMAIL PROTECTED]> wrote: > Brad Nicholes wrote: > >> So here was the thinking behind it when AuthzMergeRules was introduced. >> Maybe there is still a bug here that needs to be addressed. >> >> > http://mail-archives.apache.org/mod_mbox/httpd-dev/200607.mbox/%3c44C4E0FA.8060 > > [EMAIL PROTECTED] >> > http://mail-archives.apache.org/mod_mbox/httpd-dev/200607.mbox/%3c44CA3C33.6720 > > [EMAIL PROTECTED] > > I'm not sure it's a bug per se, but rather, an unexpected break from > the intuition developed by administrators used to configuring 2.2.x and > prior versions about how authorization cascades through configuration > blocks. I may be wrong about this, but here's how I'd expect the > example from your second thread to work. The example is: > > <Directory /www/pages> > Reject ip 127.0.0.1 > </Directory> > > <Directory /www/pages/secure> > Authtype Basic > ... > <SatisfyAll> > Require valid-user > Reject user joe > </SatisfyAll> > </Directory> > > My hunch is that prior to 2.2, the fundamental logic when merging > authz rules across blocks was neither AND nor OR, but "reset". > That is, it relies on the configuration walks to find the authz > directives in the most closely relevant block. Those directives > are then applied; what appeared in less relevant blocks is ignored. > I haven't looked closely at the logic, but that's what seems to happen > if you've got something like: > > <Directory /htdocs> > Require valid-user > </Directory> > <Directory /htdocs/admin> > Require user admin > </Directory> > > So in your example, my "configuration intuition" suggest that only > what appears in the <Directory /www/pages/secure> block applies to > anything under /www/pages/secure, and that the "Reject ip 127.0.0.1" > would just not applied at all to these URIs. So I'd expect that > to access /www/pages/secure I'd need to be any valid user except "joe"; > whether I was connecting from 127.0.0.1 wouldn't matter. > > Now, within a block, having OR be the default merge logic would > seem to make sense; if you want AND, you need <SatisfyAll>. So: > > <Directory /www/pages/secure> > Require user betty > Require user joe > </Directory> > > means "betty" and "joe" alone have access, regardless of what applied > to /www/pages. But if the following is also configured, then a "reset" > rule across blocks would mean that it does what one expects; "betty" > and "joe" would be rejected along with everyone else when attempting > to access URIs under /www/pages/secure/really. > > <Directory /www/pages/secure/really> > Require all denied > </Directory> > > This would presumably work identically: > > <Directory /www/pages/secure/really> > Reject all granted > </Directory> > > Anyway, that's a bit of a shot in the dark. Hope it helps. Thanks, > > Chris.
So I believe that the behavior that you have described could be accomplished by just switching the default of AuthzMergeRules from ON to OFF. The only case that I am still worried about is the following: <Directory /www/pages> Reject ip 127.0.0.1 //Or any other Require directive </Directory> <Directory /www/pages/whatever> ... </Directory> Since the /www/pages/whatever directory did not specify any authz, what should happen? If the AuthzMergeRules is OFF then what is the authz for /www/pages/whatever? I'm not sure that 'all granted' is correct but then neither is 'all denied'. Since the AuthzMergeRules is OFF then merging the authz would be counter intuitive. If AuthzMergeRules is ON then 127.0.0.1 is rejected and all others are allowed. I guess the thinking was that leaving the default ON would leave fewer unknowns however in some instances may not be as intuitive. Brad
