Chris Darroch wrote:
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.
Here's a follow-up notion; admittedly, it represents a lot of
re-refactoring work. It would provide an secure upgrade path for
people with complex configurations, including those with many
legacy .htaccess files to consider.
A new directive, Accept, is introduced to take the place of
Require. It functions as Require does now in 2.4. Thus we
have two groups of authz directives, old (Require/Satisfy/Order/
Deny/Allow) and new (Accept/Reject/<SatisfyOne>/<SatisfyAll>).
The old directives function as they did in 2.2. Authz directives
would be parsed and merged as follows:
1) Within a per-dir config block (<Location>/<Directory>/etc.)
old and new authz directives may not be mixed. If directives
from both groups appear, a config-time error is thrown.
2) When merging new authz directives within a per-dir config
block, the default merge rule is OR, as in 2.4 at present.
This is equivalent to using a <SatisfyOne> around all new authz
directives within a per-dir config block.
3) When merging per-dir config blocks at runtime, the following
rules are applied; we'll call the parent block "base" and the
child block "new":
3.1) If the new block contains no authz directives, the base's
authz configuration is inherited (if any). This follows
current 2.2 behaviour.
3.2) If the new block contains old authz directives, the base
block's authz configuration is discarded, and the new block's
authz directives are applied to a clean slate. This follows
current 2.2 behaviour.
3.3) If the new block contains new authz directives, the base
and new blocks' authz configurations are merged using
the rule specified by AuthzMergeRules (as it appears within
the new block):
3.3.1) If AuthzMergeRules is set to Off or is not defined,
the base block's authz configuration is discarded,
and the new block's authz directives are applied to a
clean slate. This follows current 2.2 behaviour, to avoid
confusion and simplify most configurations.
3.3.2) If AuthzMergeRules is set to Or or SatisfyOne, the base
block's authz configuration is merged with the new block's
as if they were collectively contained within a <SatisfyOne>
block.
3.3.3) If AuthzMergeRules is set to And or SatisfyAll, the base
block's authz configuration is merged with the new block's
as if they were collectively contained within a <SatisfyAll>
block.
Writing that all out it mostly just seems like a depressingly
large amount of work, but otherwise feels like it might offer a
way forward, both for people upgrading from 2.2 and those starting
fresh with 2.4. Thoughts?
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
