Назад | Перейти на главную страницу

Настройте Centos7 Apache 2.4 php-fpm для запуска от имени пользователя

Я хотел бы настроить Centos 7 Apache 2.4 Linode для использования php-fpm для выполнения php в качестве владельца файла. Документация для более ранних версий Centos6 / Apache2.2 не работает, а конфигурации, которые я видел для настройки серверов Lamp на Centos7, запускаются только от имени пользователя apache. Есть ли какие-нибудь хорошие учебники для этого или кто-нибудь может предоставить файлы конфигурации и директивы виртуального хоста, необходимые для этого? Спасибо.

Предлагаемое вами решение имеет дополнительную потенциальную проблему безопасности, помимо упомянутой в статье, на которую вы ссылаетесь в своем ответе ... из-за того, что OpCache (по умолчанию) использует один кеш для всех пользователей в среде общего хостинга. . А ошибка была отправлена (и вы можете и должны пойти и проголосовать, чтобы сообщить сопровождающим, насколько это важно для вашего варианта использования), хотя никаких обязательств по доставке исправления принято не было.

TL; DR: по умолчанию, когда OpCache включен, кеш, который используется для хранения скомпилированного байтового кода, является общим для всех пользователей. В среде, где хостинг совместно используется несколькими сайтами / пользователями, это может привести к тому, что сайт захватит кэшированный вывод php-скриптов с другого сайта или, если включены определенные параметры безопасности, даже приведет к возникновению ошибок.

Если вы планируете использовать PHP-FPM со встроенным opcache PHP 5.5+, пожалуйста, прочтите сообщение в блоге ниже, прежде чем вы действительно это сделаете. Оказывается, кэш опкодов может прочитать любой пользователь на сервере. Это означает, что если есть, скажем, 10 отдельных пользователей со своими собственными vhosts и каталогами, и вы настраиваете один пул PHP-FPM для каждого пользователя, каждый пользователь по-прежнему может видеть, какие скрипты кэшированы и их расположение. Поскольку у них есть доступ на чтение кеша, они потенциально могут просматривать все эти данные.

Это, очевидно, серьезная проблема безопасности, и даже если никто не воспользуется этим, все еще существует вероятность того, что скрипты будут прочитаны неправильным пользователем при создании страницы, поэтому веб-сайты могут отображать неправильные данные / информацию, если есть несколько индексов .php скрипты в кеше.

Хотя официально исправлений не было, если вы используете cPanel, В этой вики есть документированный способ настройки пулов php-fpm, которые будут создаваться и защищаться для каждого пользователя. и если вы будете следовать инструкциям ниже, а также ВАЖНЫЕ ЗАМЕТКИ внизу этого ответа вы сможете получить желаемую функциональность без каких-либо ошибок.

В этом посте также описывается, как вы можете настроить это вручную для каждого сайта / пользователя (хотя я готов поспорить, что это может стать утомительным, если вы размещаете много сайтов). Если вы не используете cPanel, вам может потребоваться изменить сценарии, чтобы указать ваши индивидуальные пути и имена пользователей вместо переменных, используемых механизмом конфигурации cPanel.


ВАЖНЫЕ ЗАМЕТКИ

Во время тестирования и дополнительных исследований мне попалось эта статья, которая дает несколько пояснений которые могут иметь отношение к вашей конкретной ситуации:

  1. Вам нужно убедиться, что opcache.use_cwd параметр установлен на true для конфигурации вашего приложения OpCache - он установлен на false по умолчанию и оставив его по умолчанию, вероятно, вызовет коллизии, если вы размещаете более одного приложения PHP в своей системе:

Прежде всего, вероятно, в каждом типичном проекте вам нужно будет убедиться, что для параметра opcache.use_cwd установлено значение true. Включение этого параметра означает, что механизм OpCache будет проверять полные пути к файлам, чтобы различать файлы с одинаковыми именами. Установка значения false приведет к конфликтам между файлами с одинаковым базовым именем.

  1. Если вы запускаете приложение на базе Zend Framework или другой подобной платформы, которая использует аннотации, вам ТАКЖЕ необходимо убедиться, что opcache.load_comments и opcache.save_comments директивы установлены на true. Вам следует перепроверить это предложение с документацией вашего приложения / фреймворка, так как большинство из них обновили свои документы конкретными инструкциями по включению правильного использования OpCache для своих систем:

Есть также параметр, который важен в инструментах и ​​фреймворках, в которых используются аннотации. Если вы используете Doctrine, Zend Framework 2 или PHP Unit, не забудьте установить для параметров opcache.load_comments и opcache.save_comments значение true. В результате комментарии к документации из ваших файлов также будут включены в предварительно скомпилированный код, созданный OpCache. Эта настройка позволит вам работать с аннотациями без сбоев.

Если ваш проект основан на определенной платформе или веб-приложении, всегда полезно проверить документацию на наличие рекомендаций относительно конфигурации OpCache.

ВАЖНЫЕ ЗАМЕТКИ


Надеюсь, это помогло - и если вы используете cPanel, оставьте комментарий, чтобы сообщить нам, как вы справились с этой частью конфигурации! См. Также этот вопрос и связанные с ним комментарии.

Частично образованный самоответ. php-fpm, в отличие от suphp, не позволяет запускаться от имени владельца сценария, но вместо этого позволяет настраивать пулы, которые указывают пользователя и группу для запуска от имени.

В Centos 7 с Apache 2.4 я нашел эти объявления в /etc/php-fpm.d как www.conf. Я создал дубликат этого файла и ввел имя пользователя одного виртуального хоста в качестве пользователя и группы и установил порт прослушивания на 9001 вместо 9000 (для каждого из них требуется уникальный порт на сокете localhost). Затем в каждом объявлении виртуального хоста вы указываете тот же порт в строке, как показано ниже:

ProxyPassMatch ^ / (..php (/.)?) $ fcgi: //127.0.0.1: 9001 / home / dancenew / public_html / dneuser / $ 1.

Обратите внимание, что указанный выше ProxyPassMatch уязвим для эксплойтов, см. CAVEATS в документации Apache WIKI по адресу https://wiki.apache.org/httpd/PHP-FPM . Возможно, кто-то может предоставить четкое руководство о том, как избежать этого эксплойта, вместо того, чтобы оставить его в качестве упражнения для малообразованного разработчика ... Я вспоминаю примеры NGINX, имеющие аналогичные проблемы, даже в том, что считалось надежным примером кода, который был скопирован множеством веб-сайтов ...