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 reason
why 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
