authzprovideralias-defined authz provider can't be used in Ubuntu14

Bug #1529355 reported by Hikari Kobayashi on 2015-12-26
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apache2 (Ubuntu)
Andreas Hasenack

Bug Description

AuthzProviderAlias are invisible to the authz provider inside a virtualhost stanza. This is a regression from hardy.

Sites affected by this bug might be leaking pages that were denied previously, because access is just granted.

[Test Case]

On trusty:
# install apache
sudo apt update
sudo apt install apache2 -y

# Add this block to /etc/apache2/sites-enabled/000-default.conf between the VirtualHost lines:

        <Directory "/var/www/html">
                 Require not blacklisted-ips
                 Require all granted

# create the file /etc/apache2/conf-enabled/authz.conf with this content:
<AuthzProviderAlias ip blacklisted-ips "">

# restart apache2:
sudo service apache2 restart

# access localhost, which should work just fine
wget localhost -O /dev/null

# observe that /var/log/apache2/error.log contains a message like this:
AH02305: no alias provider found for 'blacklisted-ips' (BUG?)

# /var/log/apache2/access.log shows a normal GET request for /, which was allowed:
"GET / HTTP/1.1" 200 11820 "-" "Wget/1.15 (linux-gnu)"

That, and the successful request, indicate the bug.

With an updated apache2 package, the following happens:

# /var/log/apache2/error.log no longer contains a line questioning "blacklisted-ips", but instead logs a 403 status:

[client] AH01630: client denied by server configuration: /var/www/html/

# same for /var/log/apache2/access.log, showing a 403 being returned to the client:

"GET / HTTP/1.1" 403 492 "-" "Wget/1.15 (linux-gnu)"

# and wget fails as it should:

$ wget localhost
--2018-11-24 16:50:28-- http://localhost/
Resolving localhost (localhost)...
Connecting to localhost (localhost)||:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
2018-11-24 16:50:28 ERROR 403: Forbidden.

[Regression Potential]
The patch was applied in apache 2.4.11. I looked for other commits after that trying to spot if there was a regression, but couldn't find any, and the same diff is present all the way up to what we have in disco now.
That being said, fixing the incorrect behavior might catch some admins by surprise: they might have been letting pages be accessed that shouldn't have, without realizing it. Or the other way around. After the upgrade, the access rule will be correctly enforced.

[Other Info]
Not at this time.

[Original Description]

Recently I updated my server from Ubuntu 12.03 LTS to Ubuntu14.03 LTS,
And I found the problem of Apache 2.4.7.
It is thought that Apache2.4.7 doesn't include authzprovideralias-defined authz provider.
So I can't set the systemuser's account to belong to Multiple organizations.
Since Apacahe2.4.11 includes authzprovideralias-defined authz provider,
I want you to make the same correspondence to Apache2.4.7.

Please put in this patch, right now!

Related branches

Please put in this patch, right now!

description: updated

Thank you Hikari Kobayashi for reporting the issue and even doing the work identifying the patch.

This was backported to 2.4.11 and therefore obviously is also in 2.4.18.
Thereby Xenial and Wily are not affected.

Note: This is a regression 2.2.22 (precise) -> 2.4.7 (trusty) since migrating from mod_authn_alias to mod_authn_core.
Settign tags accordingly.

tags: added: regression-release trusty
Changed in apache2 (Ubuntu):
status: New → Triaged
importance: Undecided → High
Changed in apache2 (Ubuntu):
assignee: nobody → farhan saleh robleh (farhn)
status: Triaged → Confirmed
Colin Watson (cjwatson) on 2018-05-23
Changed in apache2 (Ubuntu):
assignee: farhan saleh robleh (farhn) → nobody
status: Confirmed → Triaged
Andreas Hasenack (ahasenack) wrote :

Confirmed the patch fixes the issue.

Without it /var/log/apache2/access.log reports this:
[Fri Nov 23 19:41:07.575706 2018] [authz_core:error] [pid 4855:tid 140320138327808] [client] AH02305: no alias provider found for 'blacklisted-ips' (BUG?)

Simple config:
root@trusty-apache:/etc/apache2# cat conf-enabled/authorized.conf
<AuthzProviderAlias ip blacklisted-ips "">

And to the default vhost, I added this:
 <Directory "/var/www/html">
         Require not blacklisted-ips
         Require all granted

Changed in apache2 (Ubuntu):
status: Triaged → In Progress
assignee: nobody → Andreas Hasenack (ahasenack)
description: updated
description: updated
description: updated
description: updated
Changed in apache2 (Ubuntu Trusty):
status: New → In Progress
assignee: nobody → Andreas Hasenack (ahasenack)
Changed in apache2 (Ubuntu):
assignee: Andreas Hasenack (ahasenack) → nobody
status: In Progress → Fix Released
description: updated
Andreas Hasenack (ahasenack) wrote :

Package uploaded to trusty-proposed, pending approval by the sru team.

Hello Hikari, or anyone else affected,

Accepted apache2 into trusty-proposed. The package will build now and be available at in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-trusty to verification-done-trusty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-trusty. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in apache2 (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed verification-needed-trusty
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.