open_basedir breaks by restricting paths to files that should be allowed; Unknown: Failed opening required '/usr/share/phpmyadmin/index.php' (include_path='.') in Unknown on line 0

[=0yP)F]|L(0YNrv]

Binary package hint: php5

In package php5 (5.3.2-1ubuntu4.6) for Ubuntu Server 10.04.1 LTS, I have a bug regarding open_basedir setting in php.ini (using libapache2-mod-php5 5.3.2-1ubuntu4.6). phpmyadmin is within the allowed open_basedir resrictions, yet there is an error anyways saying it's not. It worked great using the configuration below with php5 (5.3.2-1ubuntu4.5) and libapache2-mod-php5 (5.3.2-1ubuntu4.5). This did not seem to affect php on fcgi for me, however this is unconfirmed as I haven't been able to fully test it out.

My configuration::
open_basedir = /home/:/tmp/:/usr/lib/php5/:/usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/

What is expected to happen::
No error, it should work seamlessly.

What happens::
I receive an error message (below)::
PHP Warning: Unknown: open_basedir restriction in effect. File(/usr/share/phpmyadmin/index.php) is not within the allowed path(s): (/home/:/tmp/:/usr/lib/php5/:/usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/) in Unknown on line 0
PHP Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0
PHP Fatal error: Unknown: Failed opening required '/usr/share/phpmyadmin/index.php' (include_path='.') in Unknown on line 0

Current workaround::
Add . to the open_basedir restrictions.
open_basedir = /home/:/tmp/:.:/usr/lib/php5/:/usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/

Alternatively, removing the forward slashes at the end of the paths also works as a workaround:
open_basedir = /home:/tmp:/usr/lib/php5:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin

Note: Please read the "open_basedir string" section at http://php.net/manual/en/ini.core.php . Using slashes at the end of the open_basedir paths is perfectly valid. Using no slashes causes a regex wildcard type matching, where /etc/phpmyadmin would also match /etc/phpmyadminasdf, but /etc/phpmyadmin/ matches ONLY that directory.

[Rocco (rocco)]

Same problem with Hardy and php 5.2, libapache2-mod-php5 5.2.4-2ubuntu5.13. Problem started just now after security upgrade. Affected all my sites. Had to remove trailing slash to get it working again, even if that will include more directories potentially. BIG problem.

[BlackDex (blackdex)]

Same problem here, it started working after removing the trailing /.
This should be fixed asap.

[Yabawock (yabawock)]

Can confirm this on lucid as well (libapache2-mod-php5)

[Stephan Jaensch (sj-sjaensch)]

I can confirm this on hardy as well as karmic. Perfectly valid open_basedir restrictions stopped working. Removing the trailing slash might be a workaround, but it actually weakens the restriction.

[=0yP)F]|L(0YNrv (ccgjsz8xdbdyyvy-deactivatedaccount)]

Agreed. This is a pretty big security risk to have weakened restrictions because it stopped working (with the only workaround being removing the trailing slash), and should be fixed asap.

[Daniel Firvida (dfirvida)]

I confirm this on maverick also

[=0yP)F]|L(0YNrv (ccgjsz8xdbdyyvy-deactivatedaccount)]

I stated in the bug description that I wasn't sure if this affected php on mod_fcgi. I've tested this out now, and it also affects it as it does on mod_php5.

[Steve Beattie (sbeattie)]

This looks to be the relevant upstream bug http://bugs.php.net/bug.php?id=53352 and commit: http://svn.php.net/viewvc?view=revision&revision=305698 that fixed it. I'm building and testing packages with that commit applied to verify it fixes the issue.

[Ondřej Surý (ondrej)]

Just a note from Debian to Ubuntu maintainers: if you have tracked (and helped) in Debian php packaging, you would be free of this shame, since this bug was already fixed in 5.3.3-5 which was released on 30th November 2010.

[BlackDex (blackdex)]

Seems there is an update for maverick

[BlackDex (blackdex)]

Same for Ubuntu Server 10.04 LTS.
Tested and worked.

Thx for the quick response.

[=0yP)F]|L(0YNrv (ccgjsz8xdbdyyvy-deactivatedaccount)]

Tested the updates on Ubuntu Server 10.04.1 LTS. The issue has been fixed. Thanks for fixing the issue so quickly!

[kapsi (kapsi)]

I got the update now on Hardy (13.01.2011 - 14:15 - Austria). The bug is fixed, thanks for quick response!

[Yabawock (yabawock)]

Can confirm the fix works on 10.04.1 LTS. Thanks!

[imagine (imagine-de)]

Bug is fixed, however the bug ID in the changelog is wrong, so the janitor didn't automatically close this bug report.

[=0yP)F]|L(0YNrv (ccgjsz8xdbdyyvy-deactivatedaccount)]

I removed the slashes and tested it out. It appears to work perfectly fine for me like it should.

[=0yP)F]|L(0YNrv (ccgjsz8xdbdyyvy-deactivatedaccount)]

Andrea: Yes, /var/www/phpmyadmin is a symlink to /usr/share/phpmyadmin, but please note that you're missing 2 more crucial paths. /etc/phpmyadmin/:/var/lib/phpmyadmin/ are also part of phpmyadmin and require to be allowed in open_basedir. May not be related to your issue, but it's the case nonetheless. :)

[=0yP)F]|L(0YNrv (ccgjsz8xdbdyyvy-deactivatedaccount)]

Oh, to also make a note, when I said earlier that I removed the slashes and tested it out.. my entry was like /home/user/public_html/, and I removed the slash at the end and it still worked. So when I said it appears to work perfectly fine for me, my test wasn't exactly the same as Andrea's and therefore this may still be a bug and issue. ;)

[Andrea Azzini (andreazzini)]

Uhm. The open_basedir has /var/lib/php which is a valid prefix for /var/lib/phpmyadmin/, and it has always (for two years until wednesday when this bug appeared) worked with this open_basedir string.

To further clarify:

[...]:/usr/share/phpmyadmin/:/var/lib/phpmyadmin/:[...] works
[...]:/usr/share/phpmyadmin:/var/lib/phpmyadmin:[...] works
[...]:/usr/share/php:/var/lib/php:[...] does not work

which seems to mean that it is now treating paths without a trailing slash as directory names instead of prefixes, which is what the specification says.

[=0yP)F]|L(0YNrv (ccgjsz8xdbdyyvy-deactivatedaccount)]

Andrea: Yes, you are correct, that should work. I wasn't debating that. If you installed phpmyadmin from the repositories, phpmyadmin calls php files from /etc/phpmyadmin and /var/lib/phpmyadmin also, as well as /usr/share/phpmyadmin. phpmyadmin will work without adding those 2 directories into open_basedir, but it breaks some functionality of phpmyadmin (notice some warning messages at the bottom of the phpmyadmin index page?). You can check those 2 directories to verify there's php files inside of them. :)

I also added the note that my test wasn't exactly like yours (and therefore your issue could still be a bug) because I wasn't using mine as a prefix (as your issue stated you were doing), even though I removed the trailing slashes. ;)

[Andrea Azzini (andreazzini)]

Sorry for bumping so impolitely, but this is grave and still not completely solved, at least in Hardy.

@James
Thanks for pointing this out. I am kind of surprised that it works without the /etc/ path but i am fixing it now anyway.

@others
Can anyone at least confirm that this is *not* an issue and it is limited to my server? That would surprise me even more, but apparently no one else noticed... Unfortunately I don't know the code well enough to attempt to submit a patch myself.

[Steve Beattie (sbeattie)]

The trailing slash issue was fixed with usn-1042-2 (http://www.ubuntu.com/usn/usn-1042-2); my apologies for messing up the changelog bug reference.

Andrea, I've reproduced the behavior you're seeing on all Ubuntu releases, as well as debian's 5.3.3-7 package in unstable. I've discussed it briefly with upstream, and this appears to be an intended behavior change. The upstream bug about it is http://bugs.php.net/bug.php?id=53597 .

[Andrea Azzini (andreazzini)]

OK, then this bug is fixed, on Ubuntu's side. Thank you!

[Dave Walker (davewalker)]

php5 (5.3.3-1ubuntu9.3) maverick-security; urgency=low

  * debian/patches/php5-CVE-2010-3436-regression.patch: update
    main/fopen_wrappers.c to include fix for open_basedir restriction
    regression (LP: #701896)
 -- Steve Beattie <email address hidden> Wed, 12 Jan 2011 07:02:44 -0800