Bug #75712 [Opn->Csd]: php-fpm's import_environment_variables impl should not copy $_ENV, $_SERVER

Edit report at https://bugs.php.net/bug.php?id=75712&edit=1 ID: 75712 Updated by: git@php.net Reported by: adam at lavoaster dot co dot uk Summary: php-fpm's import_environment_variables impl should not copy $_ENV, $_SERVER -Status: Open +Status: Closed Type: Bug Package: FPM related Operating System: linux PHP Version: 7.1.12 Block user comment: N Private report: N New Comment: Automatic comment on behalf of bukka Revision: https://github.com/php/php-src/commit/bc30ae4f04a2c7282f00ff1d978c0e54e23128e3 Log: Fix bug #75712: getenv in php-fpm should not read $_ENV, $_SERVER Previous Comments: ------------------------------------------------------------------------ [2024-01-19 14:57:06] bukka@php.net The following pull request has been associated: Patch Name: Fix bug #75712: getenv in php-fpm should not read $_ENV, $_SERVER On GitHub: https://github.com/php/php-src/pull/13195 Patch: https://github.com/php/php-src/pull/13195.patch ------------------------------------------------------------------------ [2018-02-11 05:20:46] requinix@php.net So I did some more digging and this behavior is caused by php-fpm specifically: PHP core has an implementation to list environment variables as an array, and php-fpm is necessarily overriding it. What it does is copy $_ENV if defined, or else $_SERVER if defined, or else fall back to the original implementation plus some FastCGI values. https://github.com/php/php-src/blob/PHP-7.1.12/sapi/fpm/fpm/fpm_main.c#L563 The ironic thing is that this started with request #69359 which wanted getenv to return an array because $_ENV is not always accessible and because it won't reflect changes made during runtime, but php-fpm's implementation (written years before when it was first introduced) does the opposite of that. So you're getting argc/v because referencing $_SERVER instructs PHP to create that variable (see the auto_globals_jit setting) which naturally includes those two, and php-fpm is giving you a copy of that array. I don't know why php-fpm wants to copy $_ENV/SERVER? Without knowing the reason for that, or exactly where else it gets used, I would think those two bits should be removed entirely... ------------------------------------------------------------------------ [2017-12-20 13:55:03] adam at lavoaster dot co dot uk Huh, yeah. If I just reference $_SERVER it will populate the return of getenv() with 'argv' and 'argc'. I'm running an nginx / php-fpm (fpm-fcgi?) setup here. ------------------------------------------------------------------------ [2017-12-20 13:34:12] requinix@php.net I haven't been able to reproduce with the CLI or the embedded server. Which SAPIs? (Apache module, FastCGI, etc.) Does it happen if you reference $_SERVER at all and not just with ['argv'], as in function notcalled() { $_SERVER; } ------------------------------------------------------------------------ [2017-12-20 13:18:06] adam at lavoaster dot co dot uk Description: ------------ This came out of looking into an issue here - https://github.com/symfony/symfony/issues/25511 If $_SERVER['argv'] exists anywhere in the code, it doesn't matter if it isn't called, just as long it's included, it will add 'argv' and 'argc' to the return of 'getenv()' when called without any parameters. Just a note: If you have xdebug installed, this issue will not present itself. Test script: --------------- <?php var_dump(getenv()); function notcalled() { $_SERVER['argv']; } Expected result: ---------------- It shouldn't return 'argv' or 'argc' in the return array, especially as 'argv' is an array which would break scripts that would directly use getenv(), like Symfony process did, straight into proc_open. Actual result: -------------- It returns 'argv' and 'argc' in the returning array. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=75712&edit=1