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.
--
Eric Covener
[EMAIL PROTECTED]
