Alternative php.ini for PHP-FPM

[sparek-3]

Is there a more eloquent way to set php-fpm to use a different php.ini file?

You can specify an alternative php.ini for php-fpm using the -c command line option. But the init script for php-fpm - /etc/init.d/ea-phpXX-php-fpm doesn't appear to provide an eloquent way of doing this. Unless I'm missing something.

The ea-phpXX-php-fpm init script has the line (using PHP 5.6 as an example, I haven't checked but I assume this applies to all versions of PHP):

daemon --pidfile ${pidfile} /opt/cpanel/ea-php56/root/usr/sbin/php-fpm --daemonize

Now, I can edit the init script to use the -c option and parameters that I want:

daemon --pidfile ${pidfile} /opt/cpanel/ea-php56/root/usr/sbin/php-fpm -c /opt/my/custom/php/ini --daemonize

But I'm worried that this change would be overwritten on subsequent PHP updates.

A better solution might be for cPanel to modify the init scripts, to include something like:

if [ -z "${EXTRAPARAMETERS}" ]
then
        EXTRAPARAMETERS=""
fi

before start() in the ea-phpXX-php-fpm init script. Then changing the start line to:

daemon --pidfile ${pidfile} /opt/cpanel/ea-php56/root/usr/sbin/php-fpm ${EXTRAPARAMETERS} --daemonize

Then users can modify the /opt/cpanel/ea-php56/root/etc/sysconfig/php-fpm file to include:

EXTRAPARAMETERS=" -c /opt/my/custom/php/ini"

Or whatever extra parameters they want to include to php-fpm.

Or does the /opt/cpanel/ea-php56/root/etc/sysconfig/php-fpm file risk being overwritten in future PHP updates? Perhaps the init script needs to include another file (i.e. /opt/cpanel/ea-php56/root/etc/sysconfig/php-fpm-extra) that does not get overwritten by updates to ea-php56-php-fpm-5.6.XX yum packages).

Or is there already a way to do this that I'm just not aware of.



Why not just make the changes I need made to the /opt/cpanel/ea-php56/root/etc/php.ini file?

Well, I recently spent more time than I care to admit troubleshooting an issue where disable_functions cannot be modified with php_admin_value directives in individual FPM pools (you can add to the directive, but you can't remove functions that exist in the php.ini file). Since EA4's PHP is tied to /opt/cpanel/ea-php56/root/etc/php.ini, I would prefer to lock down /opt/cpanel/ea-php56/root/etc/php.ini as much as possible (i.e. a default case, in case something doesn't get tied to my customized php.ini file it will default to this highly locked down php.ini). By specifying an alternative php.ini in php-fpm's startup, I can disable disable_functions in the php.ini file and set disable_functions per pool using php_admin_values for each pool.

And just to be clear, I'm not talking about per pool php.ini files. I don't believe this is possible. I seem to recall seeing some discussion about this. I'm just talking about the master php-fpm process, the php.ini file that it uses and passes on to the pools.

 

[cPanelMichael]

Why not just make the changes I need made to the /opt/cpanel/ea-php56/root/etc/php.ini file?

Well, I recently spent more time than I care to admit troubleshooting an issue where disable_functions cannot be modified with php_admin_value directives in individual FPM pools (you can add to the directive, but you can't remove functions that exist in the php.ini file). Since EA4's PHP is tied to /opt/cpanel/ea-php56/root/etc/php.ini, I would prefer to lock down /opt/cpanel/ea-php56/root/etc/php.ini as much as possible (i.e. a default case, in case something doesn't get tied to my customized php.ini file it will default to this highly locked down php.ini). By specifying an alternative php.ini in php-fpm's startup, I can disable disable_functions in the php.ini file and set disable_functions per pool using php_admin_values for each pool.

Hello,

Could you provide some clarification on why you prefer to use a separate php.ini with PHP-FPM? For instance, what are the drawbacks to using individual php.ini files via the standard method offered with EasyApache 4?

Thank you.

 

[sparek-3]

Well, say you want to disable the PHP system() function across the board, i.e. you don't want any user to use the system() function by default.

But you have one user, user1, that you trust and they need to use the system() function.

If you use PHP-FPM, if you include

disable_functions = system

in the /opt/cpanel/ea-php56/root/etc/php.ini file

Then you are stuck. You can't enable system() for user1, not without completely removing it for every user in the /opt/cpanel/ea-php56/root/etc/php.ini file.



A workaround would be to leave disable_functions empty in /opt/cpanel/ea-php56/root/etc/php.ini and then include in each user's fpm pool:

php_admin_value[disable_functions] = "system"

But for user1's pool modify this to leave it blank:

php_admin_value[disable_functions] = ""

This would work, except it leaves the disable_functions in /opt/cpanel/ea-php56/root/etc/php.ini open.



This is why I think being able to specify an alternative php.ini for php-fpm, one with disable_functions empty, would make sense. If a rogue user tries to run PHP with their own set of extensions, i.e. adding:

AddHandler application/x-httpd-ea-php56 .html

to their .htaccess file, they get caught with the /opt/cpanel/ea-php56/root/etc/php.ini which still has system in the disable_functions directive. But if you leave disable_functions empty in /opt/cpanel/ea-php56/root/etc/php.ini and depending solely on php_admin_value[disable_functions] values in FPM pools, then you're allowing this rogue user to run system() in their .html files


The idea being that you leave /opt/cpanel/ea-php56/root/etc/php.ini with the most restrictions you feel comfortable with, and then relax those restrictions for users that you trust using php_admin_value and php_value directives in each user's pool. This is the default-deny concept. Except that disable_functions is one of those weird directives that you can't remove values from. Functions listed in the disable_functions in the php.ini file can't be removed with a php_admin_value directive.


Further, I just think being able to pass extra options to /opt/cpanel/ea-php56/root/usr/sbin/php-fpm makes sense.


I've actually just gone through and wrote patches to patch the init scripts fo ea-phpXX as I figure movement on this would be slow anyway.