Chris Darroch
Tue, 08 Apr 2008 14:55:27 -0700
Brad Nicholes wrote:
Your assumptions about how the 2.2 per-dir merging is correct. Unfortunately the same concepts no longer apply to 2.4. The reasonwhy is this: <Directory /www/pages> <SatisfyAll> Require ip 10.10.0.1 Require ldap-group sales <SatisfyOne> Require ldap-group ne-sales Require ldap-group sw-sales </SatisfyOne> </SatisfyAll> </Directory><Directory /www/pages/images>## still protected Dav filesystem </Directory><Directory /www/pages/private>Require ldap-group marketing </Directory> Which ldap-group is overridden vs merged? Since the 2.2 authz had no concept of logic and was simply a list of require statements, it was very easy to add to the list or override an entry in the list. This is no longer the case. The require statements have to be merged according to some type of logic rules. Your suggestion would work if /www/pages/private simply reset and applied only the require statements it found in its own directory block (ie. AuthzMergeRules OFF), but picking the inherited logic apart and trying to rework it, won't really work.
Ideally, perhaps, it would be possible to throw a configuration-time error indicating that there was ambiguity here. However, since it's going to be effectively impossible to pre-determine all the possible <Directory>, <Location>, etc. blocks which might apply to a particular request (and in which order), that's not really possible. As you say, picking things apart isn't going to work either. One alternative is, as we've discussed, a default "AuthzMergeRules Off" state which would blank the slate when a per-dir config block contained any of Require/Reject/<SastifyAll>/<SastifyOne>. What would happen, though, if the default merge rule between per-dir configuration blocks was AND? (Within a block, OR would presumably still make sense.) I have a head cold today, and so may be making even less sense than usual, but I think this would at least ensure that people's configurations got gradually "tighter" and more restrictive as blocks were merged together down through the location and directory hierarchies. It might take an administrator a while after upgrading to figure out why they couldn't access something anymore, but at least they wouldn't have opened anything up unexpectedly.
BTW, one of the main reasons why the logic operators were added to authz was to solve the problem that existed in 2.2. The problem was that if multiple require statements appeared in a single directory block or in a hierarchy, you never really knew in which order they were actually applied. Basically it came down to the order in which the authz modules happen to have been loaded.
And there's no easy way, I think, to "turn off" authz completely, a "Require all granted" ... the 2.2 docs refer you to using "Sastify All" and "Allow from all". 2.4 is much cleaner, no doubt. My concern just really comes down to the fact that I'm fairly sure that a default OR merge rule between per-dir configuration blocks will lead people into thinking they've secured a subdirectory, when in fact they haven't, because their more-secure rule will be silently short-circuited by less-secure authz rules from above. Here's another thought: for people doing mass virtual hosting, and who let their customers put authn/z directives into .htaccess files with "AllowOverride AuthConfig", I would think it may be important to ensure that these rules still merge together in the way they used to. Otherwise upgrading to 2.4 might mean tracking down every .htaccess file and rewriting it to do the right thing (sticking in an "AuthzMergeRules Off" or something). For some people doing vhosting I suspect that would be a tall order, so it would be good if 2.4 would function securely in this situation, by default. That said, I don't use .htaccess files and may not be making any sense today; my apologies. Thanks, Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B