httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <bnicho...@novell.com>
Subject Re: Merging branch authz-dev - Authorization and Access Control 2.3 vs. 2.2
Date Sat, 07 Jan 2006 04:34:57 GMT


>>> On 1/6/2006 at 5:45 pm, in message
<e498c1660601061645g528960cdp63f2b60ecbbb58b1@mail.gmail.com>,
joshua@slive.ca 
wrote:
> On 1/6/06, Brad Nicholes <BNICHOLES@novell.com> wrote:
>>    The Authz refactoring in /branch/authz-dev is basically done and
I am
>> about ready to  merge the branch back into trunk.  Before I do that,
I
>> would like to describe the impact  that the Authz change will have
going
>> forward, as well as the benefits.  All of this  looks like a
massive
>> change to authorization and access control, which granted it is.
>> However, I have tried as much as possible to minimize the impact to
>> existing  configuration files.
> 
> These are my comments based on a very superficial look.
> 
> First, I think the overall idea is great and much clearer than what
we have 
> now.
> 
> But I do think the necessary config changes are rather massive,
> touching a large percentage of .htaccess files and <Directory>
> sections, not to mention third-party auth modules.  I would think
> that, by sacrificing some purity, it should be possible to support
> many of these configs and modules.  For example, shouldn't it be
> possible to create a mod_access_deprecated that impliments
> Order/Allow/Deny?  Obviously satisfy would add a lot of
complication,
> but I bet 90%+ of existing configs would work fine if the default
> Satisfy All was made to work, so the Satisfy directive itself
probably
> wouldn't need to be included.
> 
  Well possibly but the problem is that Order/Allow/Deny implements
access control independently from the rest of the authorization.  The
point is to try to bring them all together and eliminate the confusion. 
It may be a bit of a pain to upgrade, but I think in the end it will all
make a lot more sense.  As for the third party auth modules, they are
going to have to make the split anyway in order to fit the current
authn/authz architecture in 2.2.  It's not a major leap for them to
modify the resulting authz module to fit the new authz model in 2.3.

> I guess an alternative would be a fancy python script to convert
> config/.htaccess files.
> 
  IMO, this would probably be the better solution.

> As far as the new config directives, a couple questions:
> 
> 1. Why split "Allow from" into "Require ip" and "Require host". 
There
> is no ambiguity between a hostname and an IP address, as far as I
> know, so it would seem more straightforward to have only "Require
> host" and let httpd figure out whether it is an IP address or
> hostname.
> 
   I believe that this could probably be done.  Basically "Allow from"
was split into the 'IP', 'Host', etc. providers because that is how it
was represented in the source code and it just naturally fell out that
way.


> 2. "Require all granted" and "Require all denied" seem a little
obtuse
> to me.  As evidence, I note that you chose to document them by
> refering to the old config, rather than explaining what they do ;-) 
> Perhaps simply "Require host *" and "Reject host *" or "Require host
> all"/"Reject host all" would be clearer alternatives.  (In the
> process, getting rid of another Require option and getting us closer
> to a more familiar config.)
> 
  Honestly, I struggled with this naming myself but really couldn't
come up with anything better that would accurately represent "Allow from
all" or "Deny from all" and still fit the authz provider model.  I'm not
sure that  "Require host all"/"Reject host all" quite fits it either
because we aren't always talking about a host.

> 3. The <RequireAll> and <RequireOne> names seem a touch confusing
> given that they apply to both require and reject directives. 
Perhaps
> back to the good old <SatisfyAll/One> or <MatchAll/One>?
> 
  Again, I struggled with this naming as well.  I'm not opposed to
changing it to <SatisfyAll>/<SatisfyOne>.  It works for me. :)

> 4. It isn't made clear anywhere whether RequireAll or RequireOne is
the 
> default.

  Yeah it probably needs to be stated somewhere,  however the default
is <RequireOne> basically because that is how it works today if you use
multiple Require directives.  I guess I kind of expected that to be
obvious.


> 
> Joshua.

Thanks for the feedback,
Brad

Mime
View raw message