mkn
open_basedir messes up all sites
January 09, 2013 02:05PM
Hi,

My fresh installation worked well for two weeks, and suddenly all sites started crashing to "open_basedir_restriction in effect".

What I had done was simply add a directive to couple of the domains (just an example below):

server {
listen 81;
server_name .thiscustomer.com;
# set variable first
set $user_lib /home/thiscustomer/libs/;
...
location ~ \.php$ {
# now set open_basedir for THIS site
fastcgi_param PHP_ADMIN_VALUE "open_basedir =$user_lib:/tmp:/usr/local/lib/php:";
.. normal stuff
}
}

This had the effect that most sites got the wrong open_basedir after a hit to the above domain, as if the open_basedir value had gone global! It seemed to switch between the two sites I had made the change to, probably depending on which of them had got a visitor last.

After removing the fastgi_param everything moved to normal again. After adding it again everything weng haywire again so the problem was very easy to reproduce. So the PHP_ADMIN_VALUE seems to be pretty dangerous and should be avoided.

regards
Markku
mkn
Re: open_basedir messes up all sites
January 10, 2013 04:06AM
An addition: The same goes for (at least some) other PHP settings. I had left another directive in the site above:

fastcgi_param PHP_VALUE "auto_prepend_file=/home/thiscustomer/lib/modules/ThisModule.class.php";

Now the result was that once somebody visited the "thiscustomer" site, the auto_prepend_value went global again and the next customer visiting any other site got error: "Cannot open /home/thiscustomer/lib/modules/ThisModule.class.php, open_basedir restrictions..." or something alike.

So it seems to me that for some reason unknown to me some of these settings go global, having their effect in every single domain. I have no idea whether this is a problem with PHP-FPM or Nginx.

Once I removed the setting from the offending domain everything worked again.

The system is nginx 1.2.6 with PHP 5.3.19 compiled with pretty standard settings.
mkn
Re: open_basedir messes up all sites
January 10, 2013 11:24AM
Actually, after heavy testing on my backup site (Centos 5.8, Nginx 1.2.6, PHP 5.3.20) there is one thing quite clear:

NEVER use domain/server specific
fastcgi_param PHP_VALUE
or
fastcgi_param PHP_ADMIN_VALUE

whe using nginx + PHP-fpm. They will break the system the way described above. It took me hours to figure out how to generate domain specific settings for PHP as reliably as it can be done in Apache. The only solution I found was edit the php.ini file and add something like this:

[HOST=thiscustomer.com]

auto_prepend_file=/home/thiscustomer/lib/modules/ThisModule.class.php
open_basedir =/home/thiscustomer:/tmp:/usr/local/lib/php

[HOST=foobar.thatcustomer.com]

auto_prepend_file=/home/thatcustomer/lib/modules/WeirdThing.class.php
open_basedir =/home/thatcustomer:/tmp:/usr/local/lib/php:/opt/foobar

This solution seems to work (fingers crossed).
Re: open_basedir messes up all sites
May 05, 2013 03:55PM
mkn Wrote:
-------------------------------------------------------
> NEVER use domain/server specific
> fastcgi_param PHP_VALUE
> or
> fastcgi_param PHP_ADMIN_VALUE

Actually, there should be no problem passing either PHP_VALUE or PHP_ADMIN_VALUE per virtual host in nginx.conf. The reasons why the values are messed up can be various.

For example, in php-fpm.conf pools are defined with master value for 'open_basedir' already set, and that same pool is used for both sites. In that case the solution is either to remove 'php_admin_value' setting from php-fpm.conf and use PHP_ADMIN_VALUE per virtual host, or create a pool per web site. With the second approach you can also limit PHP user/group access to files per pool/host, resulting in that files from another pool/host cannot be accessed by the first pool and vice-versa.

Another note worth mentioning is that values configured in [HOST=...] and [PATH=...] sections are considered as master values which cannot be overwritten by PHP_(ADMIN_)VALUE in nginx,conf, or using PHP functions like ini_set().

Anyway, the following example demonstrates the working PHP_ADMIN_VALUE "open_basedir=...."; approach using nginx:

# test site
server {
listen 80;
server_name testsite1;

root /opt/www/testsite1;

location ~ \.php$ {
include fastcgi_params;
fastcgi_param PHP_ADMIN_VALUE "open_basedir=$document_root;
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;
}
}

server {
listen 80;
server_name testsite2;

root /opt/www/testsite2;

location ~ \.php$ {
include fastcgi_params;
fastcgi_param PHP_ADMIN_VALUE "open_basedir=$document_root;
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;
}
}

As you can see from the above, both virtual hosts, testsite1 and testsite2 use the same PHP-FPM pool.

When accessing http://testsite1/phpinfo.php:

open_basedir => local value: /opt/www/testsite1 master value: /opt/www/testsite1

When accessing http://testsite2/phpinfo.php:

open_basedir => local value: /opt/www/testsite2 master value: /opt/www/testsite2

This is provided there are no php_admin_value's in php-fpm.conf and no open_basedir settings in [HOST=....] or [PATH=...] configurations in php.ini or any other included configuration files.

Andrejs
Re: open_basedir messes up all sites
November 13, 2019 11:33AM
Mine has the same problem, and I found that configure open_basedir by .user.ini is all right.

https://www.php.net/manual/en/configuration.file.per-user.php
Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 170
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 500 on July 15, 2024
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready