2

After updating our server to Debian Jessie (8.3), I switched Apache 2.4.10 from mpm_worker/mod_php to mpm_event/proxy_fcgi/php-fpm. I have the handoff configured for all virtual hosts as such:

# cat conf-enabled/php5-fpm.conf 
<FilesMatch \.php$>
    SetHandler "proxy:unix:/var/run/php5-fpm.sock|fcgi://localhost/"
</FilesMatch>

I have also disabled mod_php. Because of that, apache will not let me have php_admin_value/php_value/php_flag directives in the VirtualHosts files.

Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration

I've read a bit about .user.ini files, but it doesn't sound like the directives I need to set will are supported in there, and I just successfully removed all the .htaccess files from my site for performance reasons, so this seems like a backward (and incompatible) approach.

The other common suggestion is to make a unique pool for each VirtualHost, but this concerns me for two reasons:

  1. Complexity of setup - right now, the configuration is super-simple
  2. Switching from socket to TCP? Am I correct in that that I need a unique TCP port per pool? Would I alternatively need a unique socket per pool?
  3. Memory allocation! This server doesn't have as much RAM as I'd like. It seems wasteful to have a bunch of php-fpm instances spun-up for the lesser-visited sites on the server.
jaydisc
  • 459
  • 1
  • 7
  • 19

2 Answers2

4

You can pass environment variables to the CGI pool from Apache configuration files:

    SetEnv PHP_ADMIN_VALUE "open_basedir=/path-to-your-doc-root"
    <FilesMatch \.php$>
        SetHandler "proxy:unix:/var/run/php5-fpm.sock|fcgi://localhost/"
    </FilesMatch>

mod_env must be enabled, and you must disable .htaccess file handling, if third party users can upload, or modify them (AllowOverride None). If you need to pass more than one variable, you must concatenate them with a newline char (\n).

A malicious user can change open_basedir or other important PHP configuration variables (ie.: disable_functions) with a simple .htaccess. I don't know if it's possible to prevent this behavior.

Reference: https://bugs.php.net/bug.php?id=51595

Dinacel
  • 41
  • 2
4

In the end, I just defined some [HOST=] sections in my /etc/php5/fpm/php.ini configuration.

http://php.net/manual/en/ini.sections.php

This felt more secure than using mod_env or .user.ini.

jaydisc
  • 459
  • 1
  • 7
  • 19
  • This worked well for me and meant that I didn't have to spin up multiple pools just to segregate error logs. Thanks for the answer! – e_i_pi Jun 15 '17 at 11:17
  • It's probably worth adding that these sections _must_ be in the standard config files (php.ini and conf.d/*) and not the _fpm_ config files (php-fpm.conf and pool.d/*). The _fpm_ config files are specifically for configuring pools so any [HOST=] sections will be creating a new pool not just adding some config. – George Aug 23 '17 at 09:07
  • can't get this to work. I'm trying to use a [PATH=...] section in my custom php.ini in conf.d. It is successfully being parsed but settings are not activated when using [PATH=...]. Any idea on this? – Hokascha Mar 01 '21 at 13:54