PHP-FPM incorrectly defines the SCRIPT_NAME variable when using Apache

[davidak]

Ubuntu 14.04.3 LTS
php5-fpm 5.5.9+dfsg-1ubuntu4.14

this bug is fixed in php 5.5.18 <https://secure.php.net/ChangeLog-5.php#5.5.18>

https://bugs.php.net/bug.php?id=65641
https://bugzilla.redhat.com/show_bug.cgi?id=1248077

Description:
------------
When using Apache + PHP_FPM, the SCRIPT_NAME variable is incorrectly set. For
example, accessing "http://127.0.0.1/sample/test.php/a/b/c", results in:

ORIG_SCRIPT_NAME:
SCRIPT_NAME: /sample/test.php/a/b/c
ORIG_SCRIPT_FILENAME: //tmp/sample/test.php/a/b/c
SCRIPT_FILENAME: //tmp/sample/test.php
PATH_INFO: /a/b/c
ORIG_PATH_INFO:

While when using mod_php, the values are:

SCRIPT_NAME: /sample/test.php
SCRIPT_FILENAME: /tmp/sample/test.php
PATH_INFO: /a/b/c

It is also working fine when using NGINX

Test script:
---------------
A sameple script to reproduce the issue:

<?php
echo("ORIG_SCRIPT_NAME: " . $_SERVER['ORIG_SCRIPT_NAME']);
echo('<br/>');

echo("SCRIPT_NAME: " . $_SERVER['SCRIPT_NAME']);
echo('<br/>');
echo("ORIG_SCRIPT_FILENAME: " . $_SERVER['ORIG_SCRIPT_FILENAME']);
echo('<br/>');

echo("SCRIPT_FILENAME: " . $_SERVER['SCRIPT_FILENAME']);
echo('<br/>');

echo("PATH_INFO: " . $_SERVER['PATH_INFO']);
echo('<br/>');

echo("ORIG_PATH_INFO: " . $_SERVER['ORIG_PATH_INFO']);
echo('<br/>');

?>

And a very simple apache conf:

Alias /sample /tmp/sample
ProxyPassMatch .*/sample/(test.php.*) fcgi://127.0.0.1:9000//tmp/sample/$1
<Directory /tmp/sample/ >
    Require all granted
</Directory>

Expected result:
----------------
ORIG_SCRIPT_NAME:
SCRIPT_NAME: /sample/test.php
ORIG_SCRIPT_FILENAME: //tmp/sample/test.php/a/b/c
SCRIPT_FILENAME: //tmp/sample/test.php
PATH_INFO: /a/b/c
ORIG_PATH_INFO:

[Ward (ward-redhat-bugs)]

Description of problem:

When using Apache + PHP_FPM, the SCRIPT_NAME variable is incorrectly set. For
example, accessing "http://127.0.0.1/sample/test.php/a/b/c", results in:

ORIG_SCRIPT_NAME:
SCRIPT_NAME: /sample/test.php/a/b/c
ORIG_SCRIPT_FILENAME: //tmp/sample/test.php/a/b/c
SCRIPT_FILENAME: //tmp/sample/test.php
PATH_INFO: /a/b/c
ORIG_PATH_INFO:

While when using mod_php, the values are:

SCRIPT_NAME: /sample/test.php
SCRIPT_FILENAME: /tmp/sample/test.php
PATH_INFO: /a/b/c

This is a PHP bug and is fixed in PHP 5.5.18: https://bugs.php.net/bug.php?id=65641
Please backport the fix. The popular package owncloud cannot be used with apache + php-fpm because of this issue: https://github.com/owncloud/core/issues/7719

Version-Release number of selected component (if applicable):
< PHP 5.5.18

How reproducible:
100%

Steps to Reproduce:
1. See example above: access "http://127.0.0.1/sample/test.php/a/b/c" with apache 2.4 and php-fpm.

Actual results:
ORIG_SCRIPT_NAME:
SCRIPT_NAME: /sample/test.php/a/b/c
ORIG_SCRIPT_FILENAME: //tmp/sample/test.php/a/b/c
SCRIPT_FILENAME: //tmp/sample/test.php
PATH_INFO: /a/b/c
ORIG_PATH_INFO:

Expected results:
SCRIPT_NAME: /sample/test.php
SCRIPT_FILENAME: /tmp/sample/test.php
PATH_INFO: /a/b/c

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

The bug sounds valid to me, but note that 14.04 users may be relying on the current behaviour. So if we fix the bug, we might break those users. On the other hand, the bug is trivial to work around (just truncate PATH_INFO from the end of SCRIPT_NAME if your deployment is affected). So I am reluctant to recommend modifying a stable release to avoid breaking existing users. Feedback welcome.

We should get this fixed in the development release though, if it isn't already. Does this bug affect 5.6.11+dfsg-1ubuntu3.1 in Xenial?

[davidak (davidak)]

thank you for the fast response.

the bug was also fixed in PHP 5.6.3 so it should be fine in Xenial.

this bug detains me from using ownCloud 8.x with FPM.

https://github.com/owncloud/core/issues/20146

i will suggest them this workaround.

[Robie Basak (racb)]

Thanks. I'll mark Fix Released as that reflects Xenial, and Won't Fix for Trusty as that is our current conclusion. But I am open to debate on this. My concern is to not break existing users by changing behaviour on them in an update automatically recommended to them. Since the workaround is so simple I'm not sure this warrants patching in a feature flag in PHP.

[Remi (remi-redhat-bugs)]

Upstream commits

https://github.com/php/php-src/commit/ee275e34c8b303945945c650d4bc90dcc2ac0b17
https://github.com/php/php-src/commit/8cac75969e5abb2b6be5bbd489d851a4f9e50979

The second is for ProxyPass.

[Remi (remi-redhat-bugs)]

This look like a duplicate of bug #1138563

[Aaditya Bagga (chk1827)]

Hi Robie Basak (racb),

Could an updated PHP package be put in trusty backports?

That way affected users (like me) could update to the version in backports while normal users would be unaffected.

Thanks.

[Aaditya Bagga (chk1827)]

Another problem that could be fixed by updating PHP:

With apache-2.4.10 (available in trusty-backports), a new method was introduced to pass files via proxy from apache to php-fpm, which solved some issues with using ProxyPassMatch available earlier.

However it does not work with php-5.5.9 available in trusty and was fixed in php-5.5.17

https://github.com/php/php-src/pull/694

So I believe that PHP should be updated to 5.5.18+ in trusty-backports.

[Robie Basak (racb)]

> Could an updated PHP package be put in trusty backports?

That's up to the Ubuntu backporters team. Please see https://wiki.ubuntu.com/UbuntuBackports for the procedure.

[Aaditya Bagga (chk1827)]

Okay, will check it out.
Thanks.

[Aaditya Bagga (chk1827)]

Hi,

I have tested PHP 5.5.37 for a couple of weeks now, so far it has worked without issue.

So if possible, please updated PHP to 5.5.38 which is the last version released by the PHP developers (not possible to request a trusty-backport since this version is not available in a later Ubuntu release).

Thanks.