Зачем Nginx с “fastcgi_pass PHP_ADMIN_VALUE ...” ломает PHP-FPM?
Представим, что на сервере хостятся несколько сайтов: alfa.ru, beta.ru и gamma.ru. Наша задача обеспечить бесперебойное функционирование и защиту этих сайтов. Представляем дальше, что сайт gamma.ru взломали злые хацкеры, которые сейчас имеют доступ даже к файловой системе (Ну не написали проверку на расширение загружаемого файла, с кем не бывает!). Единственный способ защитить 2 других сайта – установить директиву open_basedir в php.ini отдельно для каждого сайта (уточняю, что сайты висят на одном пуле, следовательно принадлежат одному пользователю (работаем с PHP-FPM)), указываем [HOST=...] и накатываем... Да только есть одно “но”: эта директива имеет уровень доступа PHP_INI_ALL, который позволяет изменять еë даже в исполняемом PHP-скрипте. Как мы знаем, хацкеры имеют доступ... На этот случай ещë предусмотрен вариант указания директив в конфигурации пула с помощью php_admin_value[...], да вот опять: сайты висят на одном пуле, то есть open_basedir надо указывать не на пул, а на каждый хост. Единственный оставшийся вариант, который я знаю, – Nginx. (Буду не против, если подскажете другие варианты. Надо пробовать всë и извлекать лучшее!)
Указываем в разделе “server” или “location” fastcgi_param PHP_ADMIN_VALUE "... = ..."; и получаем полный облом. Возможно, я просто дурак, но после такого указания PHP отвечает пустой страницей с длиной, естественно, 0 байт. Удаляю – страница выводится, возвращаю – опять нет. Самое интересное в этом всëм то, что продампив обмен Nginx’a с PHP-FPM (и обратно) tcpdump’ом, ответ от PHP приходит, это не Nginx что-то мутит, да только пустой (точнее сказать, только заголовки). Проще говоря, PHP перестаëт исполнять код, о чëм дополнительно свидетельствует время исполнения – 0.001 секунды, исходя из логов, собираемых Nginx’ом.
Ещë могу отметить, что задав эту директорию в разделе “http”, PHP исполняет скрипт, да только не учитывает эти директивы: в случае с “server” или “location” они передаются до основных директив, без которых ни при каких условиях не запустится скрипт (наподобие корня или запрашиваемого файла), а вот в случае с “http” – после.
Много букв, никакой особой конкретики, но мой хрустальный шар с вероятностью 99% показывает что автор просто не прочитал документацию, в частности:
fastcgi_param
[...]
Директивы наследуются с предыдущего уровня конфигурации при условии, что на данном уровне не описаны свои директивы fastcgi_param
[...]
и указывая fastcgi_param на уровне location вы «стираете» все аналогичные директивы которые были заданы на уровне server и http.
Вы доказали, что я невнимательный. Действительно, при указании fastcgi_param в разделе “location”, если на верхнем уровне есть другие fastcgi_param, они полностью перезапишутся, на что я также не обратил внимание при дампе пакетов. При этом выставили всë так, как будто вы всегда всë знаете, ничего из виду не упускаете.
Касательно всë той же многобуквенной претензии. Всю основную суть вопроса я изложил, какой конкретики не хватило, честно, не понимаю. Возможно, примера конфига Nginx’a, но вы же сделали вывод исходя из того, что было?)
Выражением “Много букв”, как понимаю, вы выразились, что много воды. Да, много. Я знаю. Написана она вся была только с целью исключения ответов по типу “Так запускай PHP-FPM для каждого сайта со своим пользователем”, при этом, такой ответ я всë же получил. Вы можете назвать его объективным? Я не могу, поэтому, чтобы не было ещë большего количества подобных ответов, вода, на мой взгляд, всë же нужна.
Важно учитывать ответ Lynn «Кофеман», он дан по существу.
А теперь о php.ini. Если директивы задаются в контексте конструкции [HOST=...], они имеют ту же силу, что и при указании php_admin_value. Говоря проще, к изменению недоступны.
Возможно об этом где-то написано на php.net, но лично я не увидел. Узнано экспериментальным путëм.
Если задача обеспечить бесперебойную работу и защиту - они должны работать от разных пользователей с разными пулами php-pfp, запущенными от тех-же разных пользователей.
Простой
