Bug 63734 - Support use-time parameters for AuthzProviderAlias
Summary: Support use-time parameters for AuthzProviderAlias
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_authz_core (show other bugs)
Version: 2.4-HEAD
Hardware: All All
: P2 enhancement with 1 vote (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-06 10:12 UTC by Ulrich Schwarz
Modified: 2019-09-06 12:19 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ulrich Schwarz 2019-09-06 10:12:48 UTC
Looking at authz_alias_check_authorization in mod_authz_core.c, it appears that all parameters for the alias must be present at define time, and parameters at use time are silently ignored. I.e.,

<AuthzProviderAlias ldap-group mygroup>
(LDAP connect settings here)
</AuthzProviderAlias>

…

Require mygroup cn=foo,…

does not do what one might expect to happen. Furthermore, there is no error/warning that mygroup does not take any parameters.

I would like to submit for consideration that it would be useful if the use case sketched above worked. (In my case, it would simplify handling against several dozen different LDAP groups without having to duplicate the credentials all over the place.)

For example, authz_alias_check_authorization could use the passed-in call-time parameters require_args and parsed_require_args it already receives anyway if the define-time parameters prvdraliasrec->provider_args and prvdraliasrec->provider_parsed_args are null.

Chances to break existing configs appear minimal: not passing parameters at define time is currently only useful for things like valid-user that do not take any parameters in the first place. Parameters passed to an alias at call-time currently are simply ignored.
Comment 1 Eric Covener 2019-09-06 10:23:55 UTC
Is this a dup of PR62469? 2.4.25 is quite old.
Comment 2 Ulrich Schwarz 2019-09-06 12:19:44 UTC
No, PR62469 was about behaviour of the definition. 
(Admittedly, part of this feature request shows we currently have similar behaviour at the usage stage, where "Require myalias foo bar" is equivalent to "Require myalias" without any warning, but the proposed feature request is not to warn, but have it do something more useful instead.)

2.4.25 is a fluke, I checked the semantics against the github mirror of the sources, and it's still like that at the tip of the 2.4 branch.