>>> On 8/30/2007 at 4:36 PM, in message
<[EMAIL PROTECTED]>, "Eric Covener"
<[EMAIL PROTECTED]> wrote:
> On 8/30/07, Brad Nicholes <[EMAIL PROTECTED]> wrote:
>> >>> On 8/29/2007 at 7:51 PM, in message
>> <[EMAIL PROTECTED]>, "Eric Covener"
>> <[EMAIL PROTECTED]> wrote:
>> >
>> > In 2.2.x If authz_XXX are one of dbm, owner, or groupfile they track
>> > the list of requires and decline if they don't see any they're
>> > responsible for -- this isn't a crap shoot of module ordering in this
>> > case.
>> >
>> > $ grep \!required *.c
>> > mod_authz_dbm.c: if (!required_group || !conf->authoritative) {
>> > mod_authz_groupfile.c: if (!required_group || !conf->authoritative) {
>> > mod_authz_owner.c: if (!required_owner || !conf->authoritative) {
>> > mod_authz_user.c: if (!required_user) {
>> >
>> > That roughly leaves authz_host, authz_default, and authnz_ldap.
>> > authz_host has a built-in default based on Order, and authz_default
>> > doesn't have any Requires to check -- leaving authnz_ldap as the odd
>> > man out.
>> >
>>
>> True, so that brings up the question of what does AuthzXXXAuthoritative
> really mean? Does it mean that if set to ON, this module is authoritatively
> responsible for authorization and if it can't (whatever the reason including
> no require statement), then authorization fails? Or does it mean that the
> module is only authoritatively responsible for authorization if a matching
> require statement exists? According to what you are saying as well as what
> the code is currently saying in the other authz modules, the latter is true.
> And if that is really the definition of AuthzXXXAuthoritative, then it
> appears that authnz_ldap needs to be fixed.
>>
>> Brad
>>
>
> For the ones in the list above it seems to roughly be:
>
> if an authz_XXX require is satisfied, return OK
> If authz_XXX is authoritative, and any authz_XXX require directives
> were present, return HTTP_UNAUTHORIZED
> else return DECLINED
>
> Any clue from a development process POV how I'd propose such a thing
> for "backport" since it doesn't apply to trunk? I was also hoping
> some more people might weigh in on the behavior change for
> mod_authnz_ldap in a stable release.
Welcome to the world of ldap development in Apache, outside of a very small
group of us, there usually isn't much response from anyone else. :( I would
suggest that you write a patch and either post the patch file in your
people.apache.org user dir so that it is easily accessible from the web or
attach it to a bugzilla bug that can be referenced. Then write your backport
proposal in the 2.2 STATUS file and reference the patch file directly rather
than a link into SVN. Also note that this is specific to 2.2 and does not
apply to trunk due to the authorization refactoring going forward.
Brad