You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brad Nicholes <BN...@novell.com> on 2007/05/02 21:32:35 UTC
Re: svn commit: r534533 - in /httpd/httpd/trunk:
include/http_core.h modules/aaa/mod_access_compat.c
modules/aaa/mod_auth.h modules/aaa/mod_authz_core.c
modules/aaa/mod_authz_default.c server/core.c server/request.c
>>> On 5/2/2007 at 11:47 AM, in message
<e4...@mail.gmail.com>, "Joshua Slive"
<jo...@slive.ca> wrote:
> On 5/2/07, bnicholes@apache.org <bn...@apache.org> wrote:
>> Author: bnicholes
>> Date: Wed May 2 09:31:39 2007
>> New Revision: 534533
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=534533
>> Log:
>> re-introduce ap_satisfies API back into core and modify how the
> access_checker, check_user_id and auth_checker hooks are called so that they
> respect the precedence that is set through the satisfy ALL/ANY directive.
> This also restores the directives order, allow, deny, satisfyas supported
> directives rather than being deprecated. These directives still remain in
> mod_access_compat however.
>>
>
> Fine. But then let's just revert mod_authz_host to the 2.2 version and
> delete mod_access_compat. (Or, in other words, rename
> mod_access_compat to mod_authz_host.) I don't see the reason for
> having two supported ways of doing the same thing.
>
> Joshua.
Yeah, that's where I mentioned that things might look a little confusing. There actually is a good reason to have both and yes some of the functionality can overlap. The reason for having mod_authz_host is so that host, IP, ENV, etc. can be used during authorization as well. This really wasn't as issue in 2.2 because the AND/OR/NOT logic didn't exist yet. Now that you can apply this type of logic to authorization, allowing host, IP, ENV, etc. to be part of that, make sense. If we moved mod_authz_host back to the 2.2 version, in the first place it would no longer be authz but just mod_access again and you wouldn't be able to include host, IP, ENV, etc. as part of an authorization rule. But I agree that mod_access_compat name no longer makes sense.
Brad
Re: svn commit: r534533 - in /httpd/httpd/trunk:
include/http_core.h modules/aaa/mod_access_compat.c
modules/aaa/mod_auth.h modules/aaa/mod_authz_core.c
modules/aaa/mod_authz_default.c server/core.c server/request.c
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 5/2/2007 at 1:47 PM, in message
<e4...@mail.gmail.com>, "Joshua Slive"
<jo...@slive.ca> wrote:
> On 5/2/07, Brad Nicholes <BN...@novell.com> wrote:
>
>>
>> Yeah, that's where I mentioned that things might look a little confusing.
> There actually is a good reason to have both and yes some of the
> functionality can overlap. The reason for having mod_authz_host is so that
> host, IP, ENV, etc. can be used during authorization as well. This really
> wasn't as issue in 2.2 because the AND/OR/NOT logic didn't exist yet. Now
> that you can apply this type of logic to authorization, allowing host, IP,
> ENV, etc. to be part of that, make sense. If we moved mod_authz_host back to
> the 2.2 version, in the first place it would no longer be authz but just
> mod_access again and you wouldn't be able to include host, IP, ENV, etc. as
> part of an authorization rule. But I agree that mod_access_compat name no
> longer makes sense.
>>
>
> What kinds of configurations are we actually talking about where
> Require ip could do things that Order/Allow/Satisfy could not? I guess
> you are talking about things like
> <SatisfyOne>
> <SatisfyAll>
> Require user john
> Require ip 192.0.0
> </SatisfyAll>
> <SatisfyAll>
> Require user bob
> Require ip 191.0.0
> </SatisfyAll>
> </SatisfyOne>
>
> Is that kind of configuration really common enough to justify the
> added complexity of two different access-control systems? (It can be
> accomplished in current versions using some Alias/Location hacks or
> with mod_rewrite.)
>
> My opinion is that either we get rid of Require ip or we fix the hook
> ordering so that Order/Allow/Satisfy/etc can really be deprecated.
>
> Joshua.
Correct, except I am thinking something more like:
<SatisfyOne>
<SatisfyAll>
Require user john
<SatisfyOne>
Require ip 192.0.0
Require ip 137.65.0
Require host myhost.org
</SatisfyOne>
</SatisfyAll>
<SatisfyAll>
Require group admins
<SatisfyOne>
Require ip 10.10.0.0
Require ldap-attribute status="highest"
</SatisfyOne>
</SatisfyAll>
</SatisfyOne>
Which may be a bit more complicated to try to duplicate using other means. Besides, it seems to be a lot more straight forward to keep all of the authorization logic in one place rather than bits and pieces spread out in mod_rewrite rules or alias/location hacks.
I'm all for figuring out a way to rework the hooks so that Order/Allow/Satisfy/etc. can really be deprecated. That is what my original intention was. However, after revisiting this issue, I'm not sure how to do it yet.
Brad
Re: svn commit: r534533 - in /httpd/httpd/trunk: include/http_core.h modules/aaa/mod_access_compat.c modules/aaa/mod_auth.h modules/aaa/mod_authz_core.c modules/aaa/mod_authz_default.c server/core.c server/request.c
Posted by Joshua Slive <jo...@slive.ca>.
On 5/2/07, Brad Nicholes <BN...@novell.com> wrote:
>
> Yeah, that's where I mentioned that things might look a little confusing. There actually is a good reason to have both and yes some of the functionality can overlap. The reason for having mod_authz_host is so that host, IP, ENV, etc. can be used during authorization as well. This really wasn't as issue in 2.2 because the AND/OR/NOT logic didn't exist yet. Now that you can apply this type of logic to authorization, allowing host, IP, ENV, etc. to be part of that, make sense. If we moved mod_authz_host back to the 2.2 version, in the first place it would no longer be authz but just mod_access again and you wouldn't be able to include host, IP, ENV, etc. as part of an authorization rule. But I agree that mod_access_compat name no longer makes sense.
>
What kinds of configurations are we actually talking about where
Require ip could do things that Order/Allow/Satisfy could not? I guess
you are talking about things like
<SatisfyOne>
<SatisfyAll>
Require user john
Require ip 192.0.0
</SatisfyAll>
<SatisfyAll>
Require user bob
Require ip 191.0.0
</SatisfyAll>
</SatisfyOne>
Is that kind of configuration really common enough to justify the
added complexity of two different access-control systems? (It can be
accomplished in current versions using some Alias/Location hacks or
with mod_rewrite.)
My opinion is that either we get rid of Require ip or we fix the hook
ordering so that Order/Allow/Satisfy/etc can really be deprecated.
Joshua.