httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: AuthzMergeRules directive
Date Thu, 10 Apr 2008 22:40:54 GMT
>>> On 4/9/2008 at 11:08 AM, in message <47FCF810.90804@pearsoncmg.com>, Chris
Darroch <chrisd@pearsoncmg.com> wrote:
> 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:
> 

I'm not real excited about adding a new authz directive.  Authn and authz are already very
complex and adding a new directive to the mix will just help to confuse people even more.
 Especially when they can't tell the difference between 'require' and 'accept' or when they
should use one or the other.  The requirement to stay somewhat backwards compatible in all
of this stuff lends to the confusion already.

> 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.
> 

I am OK with this one except for the reason that I mentioned before.  By allowing authz to
be inherited even when AuthzMergeRules is OFF is kind of a conflict.  In other words, since
AuthzMergeRules OFF implies  an AND, 1 AND 0 should be 0 or no authz rather than inherited
authz.  However I could buy into this if it seems to make more intuitive sense to the user.
 
>  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):
> 

This is where things get a little confusing for me.  I'm not really too excited about authz
logic behavior changing just because of which version of an authz directive you used.  This
type of change in behavior isn't intuitive.  At least with the way it is now,the behavior
change would be between 2.2 and 2.4 rather than two different behaviors in 2.4 itself.

>   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.
> 

This could be OK however I'm not real comfortable with specifying the merging logic in two
different ways.  In other words, if AuthzMergeRules is set to OR yet <SatisfyAll> is
also specified in the same block.  The new authz directives may take a little getting used
to when first used, but at least there is a consistent way to do things and a behavior that
will be consistent in 2.4 without having to worry a lot about "what if"s.  

>    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?
> 

In the end I am all for whatever will make life easier for the person who has to do configuration.
 The downside to authn and authz is that it has become more complex, the up side is that it
has also become more powerful and predictable. I'm just not sure what the right compromise
is.

Brad


Mime
View raw message