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 2008/01/04 21:10:17 UTC
Re: httpd trunk - How to get info that ap_requires used to
return
>>> On 1/4/2008 at 10:12 AM, in message
<7e...@mail.gmail.com>, "Rolf Banting"
<ro...@gmail.com> wrote:
> Folks,
>
> I want to build mod_perl 2 against httpd trunk but
> I've encountered a few road-blocks. The one that has held me up
> recently is to do with the removal of ap_requires from the httpd
> source sometime since httpd
> 2.2.6.
>
> The mod_perl test suite includes several tests that rely on ap_requires to
> dig out Require data e.g
> Require user shaun
> Require group sheep
>
> These obviously now fail when mp is built against the httpd trunk.
>
> Presumably there are other straightforward
> ways to get at the Require configuration for a given directory?
>
> I have had a scout round - the mod_authz code uses the require_line
> data structure but I can't
> immediately see how this can be related to mod_perl.
>
> Thanks,
>
> Rolf
Well, I'm not sure you are going to like the answer. The authz functionality has been completely rearchitected in httpd trunk. Rather than being hooked based which required every authz module in the chain to evaluate all of the require statements, it is now provider based. Basically what this means is that an authz module simply registers the authz types that it supports and then the provider for that authz type is only called when needed. In addition to being provider based, a new logic concept has been added to allow the user to combine different authz types using simple logic groupings. In this architecture, the functionality that ap_requires() performed, no longer makes. The 'Require' statement(s) within a <Directory> block is no longer just a single authz type or list of types, the authz result must be evaluated within the logical context in which it exists. Under the old architecture, ap_requires() returned a simply list of authz types. In the new architecture, the authz types that are included in a <Directory> block are no longer a list, but rather a logic tree.
Since I don't know how the perl test suite works, I couldn't really tell you how the suite must be rearchitected to fit the new model. I vaguely remember having this discussion with somebody a year or more ago. You might want to check the list archive. Other than that, we would just have to discuss what the test suite is doing and how it might be reworked.
Brad
Re: httpd trunk - How to get info that ap_requires used to return
Posted by Rolf Banting <ro...@gmail.com>.
Thanks Brad, that certainly clears things up for me.
I haven't got time at the moment to work out what the new scheme means for
mod_perl in general. For now I will work around it.
Rolf
Re: httpd trunk - How to get info that ap_requires used to
return
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 1/7/2008 at 4:56 AM, in message
<7e...@mail.gmail.com>, "Rolf Banting"
<ro...@gmail.com> wrote:
>>
>> My immediate aim is to test Isaac's UDP support patch with mod_perl - I
>> want to make a case for apache as a viable alternative for our service
>> platform and udp support is essential. If I can get the mod_perl test suite
>> to pass I increase the credibility of my proposal.
>
>
> The mod_perl tests that use ap_requires are quite simple - the Require
> lines are retrieved via ap_requires and then the values compared against
> data in the current request. Example:
>
> In the conf:
>
> Require user goo bar
> Require group bar tar
>
> In the test code:
>
> # extract just the requirement entries
> my %require =
> map { my ($k, $v) = split /\s+/, $_->{requirement}, 2; ($k, $v||'') }
> @{ $r->requires };
> debug \%require;
>
> ....
>
> return Apache2::Const::SERVER_ERROR unless $require{user} eq $users;
> return Apache2::Const::SERVER_ERROR unless $require{group} eq $groups;
>
> $require{user} should be 'goo bar'
> $require{group} should be 'bar tar'
>
> I don't yet have much detailed knowledge of the httpd code - my naive
> interpretation is that ap_requires returned a list of require_line structs
> where the 'requirement' field is
> everything after the 'Require' in the config line. If there was some
> way to get a list of the Require statements in the conf file it would
> be an easy matter to re-jig the test code.
>
> I suppose I could parse the config file directly (e.g. with Config::General
> )
> to get the Require lines - but I would prefer to use any in-built httpd
> support if possible.
>
> From my naive perspective I'd offer that per-directory queries for
> configuration
> information such as all Require statements are useful things to have.
>
The problem is that the Require statements are no longer stored as a list of require_line structs so retrieving them as such isn't possible. The Require statements are added to a logic tree as they are read from the configuration and then whenever authorization is done for that <Directory>, the logic tree is traversed and a result is returned. Obviously if there is only a single Require statement in the <Directory>, the logic tree would be very simple, but this isn't something that you can count on. The authorization logic could be anything. As far as the configuration file is concerned, it could look like anything from
Require User goo bar
Require Group bar tar
which would be interpreted as:
if (User == 'goo') || (User == 'bar') || (Group == 'bar') || (Group == 'tar') then
allow
else
deny
to:
Require User goo
<SatisfyAll>
Require Group foo
<SatisfyOne>
Require User bar
Require Group tar
</SatisfyOne>
</SatisfyAll>
which is interpreted as:
If (user == 'goo') || (group == 'foo' && (User == 'bar' || Group == 'tar')) then
Allow
else
Deny
It appears that your test script doesn't really care about the authorization result but rather if a Require statement simply exists with a given value. At this point there isn't a way to get that information through an API. I guess an API could be added that given a specific value would traverse the logic tree to validate that a matching Require statement exists. But outside of the Perl test, I'm not sure what usefulness an API like that would have.
Brad
Re: httpd trunk - How to get info that ap_requires used to return
Posted by Rolf Banting <ro...@gmail.com>.
>
> My immediate aim is to test Isaac's UDP support patch with mod_perl - I
> want to make a case for apache as a viable alternative for our service
> platform and udp support is essential. If I can get the mod_perl test suite
> to pass I increase the credibility of my proposal.
The mod_perl tests that use ap_requires are quite simple - the Require
lines are retrieved via ap_requires and then the values compared against
data in the current request. Example:
In the conf:
Require user goo bar
Require group bar tar
In the test code:
# extract just the requirement entries
my %require =
map { my ($k, $v) = split /\s+/, $_->{requirement}, 2; ($k, $v||'') }
@{ $r->requires };
debug \%require;
....
return Apache2::Const::SERVER_ERROR unless $require{user} eq $users;
return Apache2::Const::SERVER_ERROR unless $require{group} eq $groups;
$require{user} should be 'goo bar'
$require{group} should be 'bar tar'
I don't yet have much detailed knowledge of the httpd code - my naive
interpretation is that ap_requires returned a list of require_line structs
where the 'requirement' field is
everything after the 'Require' in the config line. If there was some
way to get a list of the Require statements in the conf file it would
be an easy matter to re-jig the test code.
I suppose I could parse the config file directly (e.g. with Config::General )
to get the Require lines - but I would prefer to use any in-built httpd
support if possible.
>From my naive perspective I'd offer that per-directory queries for
configuration
information such as all Require statements are useful things to have.
I intend no criticism of the re-design.
Regards,
Rolf
Re: httpd trunk - How to get info that ap_requires used
to return
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 1/4/2008 at 1:17 PM, in message <47...@rowe-clan.net>, "William
A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
> Brad Nicholes wrote:
>>
>> Since I don't know how the perl test suite works, I couldn't
>> really tell you how the suite must be rearchitected to fit the
>> new model. I vaguely remember having this discussion with
>> somebody a year or more ago. You might want to check the list
>> archive. Other than that, we would just have to discuss what
>> the test suite is doing and how it might be reworked.
>
> How about a pointer to the patch applied to a prior module or two
> which replaces ap_requires with the new logic?
>
> It's not the framework - it's modperl itself I believe that is
> the prime issue. The new interfaces need to be built.
>
> Bill
That would be a bit difficult because the difference between a prior module and a new module is night and day. Basically it is the difference between an apache 2.2.x authz module and the same authz module in trunk (compare mod_authz_user.c in both 2.2 branch and trunk or http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/aaa/mod_authz_user.c?r1=332306&r2=368027&diff_format=h). They don't compare well because it is a completely different architecture.
If we are talking about converting a hook based authz to a provider based authz in mod_perl, then that is something different and very doable. In fact my 'Modular Auth Arch' talk at ApacheCon a couple of months ago walks you through the conversion (http://people.apache.org/~bnicholes/presentations/). The original message sounded like it was the test suites that needed to be refactored.
Brad
Re: httpd trunk - How to get info that ap_requires used to return
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Brad Nicholes wrote:
>
> Since I don't know how the perl test suite works, I couldn't
> really tell you how the suite must be rearchitected to fit the
> new model. I vaguely remember having this discussion with
> somebody a year or more ago. You might want to check the list
> archive. Other than that, we would just have to discuss what
> the test suite is doing and how it might be reworked.
How about a pointer to the patch applied to a prior module or two
which replaces ap_requires with the new logic?
It's not the framework - it's modperl itself I believe that is
the prime issue. The new interfaces need to be built.
Bill