Шаманград

Широко используемым решением для разделяемого виртуального хостинга является связка Apache + PHP. PHP реализован в качестве модуля Apache и для обеспечения безопасности обычно достаточно заблокировать в php.ini функции типа exec и задать в настройках виртуального узла значение open_basedir при помощи директивы php_admin_value

Для решения вопросов, касающихся безопасности при использовании Apache, тема уже есть.

Проблема возникает, когда нужно решать вопросы безопасности в связке nginx + php-fpm. В чём проблема? А в том, что возможности передать серверу PHP значение open_basedir из nginx нет. Как ни крути, пользователю не составит проблемы выйти за пределы своего домашнего каталога и смотреть чужие файлы (а в них можно порой подсмотреть пароли на MySQL-сервер и так далее).
Наиболее оптимальным решением в такой ситуации, возможно, является использование chroot. php-fpm поддерживает chroot на уровне своего конфигурационного файла. В секции <workers> имеется возможность сделать сколько угодно пулов рабочих процессов php-cgi, для каждого из пулов можно указать chroot. Чтобы различать пулы, нужно «вешать» их на разные порты TCP/IP или разные UNIX-сокеты.



Возникает несколько новых серьёзных проблем. Рассмотрим их.

1. Каждый пул рабочих процессов «ест» память. Причём если какой-то виртуальный узел напрягается, а другой простаивает, то рабочие процессы второго узла «не смогут» помочь первому. Проблема особенно остра для VDS-серверов, где ресурсы всегда стоят денег владельцу сервера.
Возможное решение: делать отдельный пул не для одного виртуального узла, а для одного пользователя (всех его виртуальных узлов). Не очень поможет, если пользователей много, а сайтов у всех по одному. Тогда, возможно, имеет смысл группировать пользователей по доверенности, создавая пул для доверенных пользователей (они смогут подсматривать друг к другу в домашние каталоги) и соответственно «недоверенных».

2. Подключение к MySQL-серверу внутри виртуального узла возможно только по TCP/IP. Некоторые веб-приложения (к примеру, WordPress) для сервера localhost даже не пытаются использовать TCP/IP, а сразу выдают сообщение об ошибке, не обнаружив сокета MySQL.
Возможное решение: жёсткая ссылка на разъём MySQL внутри chroot-окружения. Важно заметить, что при перезапуске MySQL-сервера ссылку необходимо пересоздавать заново.

3. обращение к URL внутри chroot приводит к ошибке (getaddrinfo failed).
Возможное решение: поместить в chroot жёсткие ссылки на следующие файлы:

• /etc/resolv.conf
• /etc/nsswitch.conf
• /lib/libnss_dns.so.2

С недавних пор FastCGI Process Manager — уже не патч, а самостоятельный проект. Интересно будет посмотреть, насколько это решило одну из проблем (когда мастер-процесс потребляет почти столько же памяти, сколько рабочие процессы).


GIT-репозиторий проекта:
git://github.com/dreamcat4/php-fpm.git

Очередной подводный камень — отправка e-mail. Обнаружилось сегодня на jsmart.web.id.

Скорее всего, нужно сделать жёсткую ссылку на /usr/bin/sendmail. Если ему нужно ещё что-то из внешнего мира, подскажите, на выходных буду делать.

Боюсь что много чего =(

Во-первых, /usr/sbin/sendmail может быть враппером для вызова реальной проги (которую в chroot-окружении тоже надо как-то найти), для postfix если не ошибаюсь это postdrop. Ему нужен как минимум конфиг /etc/postfix/main.cf и может быть ещё что-то. postdrop записывает письмо в каталог /var/spool/postfix/maildrop откуда MTA уже по расписанию делает отправку. Вот тут тоже хз, толи она напрямую записывает в этот каталог или использует unix-сокет (возможно /var/spool/postfix/private/maildrop )

По всей видимости это будет более сложная проблема. Если вариант, то использовать phpMailer с работой через SMTP. С учетом твоих проблем с памятью включать SMTP-сервер тоже проблематично.

Итак, очередной серьёзной проблемой на пути к использованию PHP в chroot-окружении стала отправка электронной почты. PHP должно вызывать программу sendmail, передавая ей некоторый список аргументов. Само письмо пишется в стандартный ввод, так ведь?
Так что моей идеей для независящего от используемого MTA решения этой проблемы будет банальный перевызов реального sendmail (вне chroot-окружения) одноимённым враппером из chroot. Как этого можно добиться? Один из вариантов пришёл на ум сразу — sendmail, работающий в chroot, просто сбрасывает письма в некоторую базу данных SQLite, которую затем (например, по cron-у раз в несколько минут) сканирует внешний сценарий. Если в базе данных есть письма, они отправляются реальным sendmail.

У кого будут варианты проще?

Использовать IPC типа D-Bus или даже сокетов для рантаймного дёргания sendmail. sendmail в chroot будет просто дёргать соответствующий сервер, пинающий настоящий sendmail.

хм.. IPC навело на следущую мысль: sendmail повесить на (x)inetd, а в chroot окружении вместо sendmail использовать minisend из nanosoft

Получается так:
1. PHP вызывает скрипт sendmail.sh
2. sendmail.sh вызывает minisend localhost <port>
3. minisend коннетиться к порту который слушает (x)inetd
4. (x)inetd запускает настоящий sendmail
5. sendmail делает свою работу

Думаю будет работать, но надо проверять =)

Хотя я бы все-таки попробовал бы сделать жесткие ссылки на sendmail, main.cf, maildrop и unix-сокет maildrop-а (см. мой предыдущий пост)

Я не хочу делать жёсткие ссылки, я хочу знать решение, пригодное для любого MTA, речь не только о сервере underjabber.net.ru.
Тока чтобы sh-скрипт в chroot вызвать, понадобится ещё bash, проще сам minisend немного переделать для конкретного случая.
Вообще говоря, у меня жестчайшее ограничение на число процессов, так что лишние процессы порождать не стоит.

И всё-таки даже если решить все проблемы в виде недоступных в chroot файлов, останется ещё одна не менее серьёзная проблема. Если безопасность обеспечивать при помощи chroot, то нужно для каждого пользователя заводить свой пул рабочих процессов. А они, как известно, весьма существенно потребляют память. Вариант, сразу всплывающий в голове, — максимально уменьшить число процессов на 1 юзера, то есть 1 процесс. Но это резко увеличивает возможность 502 ошибки в случаях, когда рабочий процесс не справляется с нагрузкой. Собственно, именно это и наблюдается у многих хостеров, использующих php-fpm и делающих по 1 процессу на пользователя с тем, чтобы разместить на одном сервере как можно больше клиентов и извлечь из этого больше $$$.

Хитрость в том, что 5-7 рабочих процессов, одновременно обслуживающих десяток пользователей, работают намного эффективнее, чем 10 процессов, обслуживающих 10 пользователей, но так, что каждый обслуживает «своего». Так что chroot в плане эффективности идёт лесом.

Нужно всё-таки придумать, как бы задавать open_basedir. Я пробовал сделать это, используя директиву php.ini auto_prepend_file, но в файле, подключаемом таким образом, нельзя переопределить open_basedir (да и многие другие параметры).

В скором времени у меня хотят захоститься несколько человек, не хотелось бы делать каждому из них по 2 процесса — хочется сделать 2 процесса на всех, сайты не такие уж и посещаемые ожидаются.

P.S.: кстати, FPM приняли в основной код PHP, так что в скором будущем его появление можно ожидать в обычных релизах.

Сделал как сказано, с учётом этой информации, теперь функция mail() приводит к 504 ошибке
Помогите, пожалуйста

504 ошибка возникала на уровне postfix, зависал, гад. Сейчас подправил конфиг, хоть и не работает, но уже не зависает. Короче, нужно донастроить postfix…

Решение проблемы найдено! В ближайшее время напишу статью на своём сайте.
Спасибо shade, что толкнул идею.

Собственно, вот, прошу прощения, что на английском.
http://the1st.net.ru/php-fastcgi.shtml

> echo file_get_contents('/opt/nginx/html/errors/404.html');
readfile

fixed