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

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.

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

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

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.

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.

I confirm this on maverick also

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.

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.

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.

Seems there is an update for maverick

Same for Ubuntu Server 10.04 LTS.
Tested and worked.

Thx for the quick response.

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

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

Can confirm the fix works on 10.04.1 LTS. Thanks!

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

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

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. :)

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. ;)

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.

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. ;)

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.

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 .

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

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