httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <chr...@pearsoncmg.com>
Subject Re: AuthzMergeRules directive
Date Wed, 09 Apr 2008 17:08:32 GMT
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


Mime
View raw message