Chrooted php-fpm, как давать доступ нжинксу?

[Фанат]

Тут на ДО появилась статья, которая объясняет то, что я как раз хочу сделать
https://www.digitalocean.com/community/tutorials/how-to-host-multiple-websites-securely-with-nginx-and-php-fpm-on-ubuntu-14-04

А именно - зачрутить пхп-фпм, чтобы колхозники не видели друг друга

Но там не освещается такой вопрос - как нжинкс будет получать доступ к не-пхп файлам?
Получается, надо добавлять владельца сайта в группу www-data - так?

 

[fixxxer]

а зачем вобще 2 разных юзера?

чрутуешь под тем же www-data, nginx-у root /path/to/chroot/path/to/docroot, в fastcgi_param-е в DOCUMENT_ROOT и SCRIPT_FILENAME - без префикса /path/to/chroot

 

[Фанат]

а зачем вобще 2 разных юзера?

это ж хостинг
то есть первый пользователь - это ползователь, а второй - нужникс.

 

[fixxxer]

А. Ну тогда да. Но в этом плане-то без разницы, чрут-не чрут

 

[Фанат]

А. Ну тогда да. Но в этом плане-то без разницы, чрут-не чрут

Ну то есть получается, что мы все равно пользователя добавляем в одну группу с нужниксом и даем чтение группе - правильно?
И это штатный вариант?
А безопасность достигается за счет того, что пхп крутится в чруте, и не дает выйти наружу - т. е. даже увидеть соседские файлы?

 

[fixxxer]

Ну дык все, что делает chroot - это меняет "корневую" директорию на указанную.

Так себе безопасность, на самом деле. В современных линуксах можно запустить процесс в отдельном неймспейсе со своими cgroups - это куда интереснее. В дистрибутивах с systemd для этого есть systemd-nspawn, в остальных пока нормальных userland средств толком нет.

 

[Фанат]

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

 

[fixxxer]

В смысле прав - нет ваще никакой разницы, чрут или не чрут.

 

[Фанат]

В смысле прав - нет ваще никакой разницы, чрут или не чрут.

Ага, понятно.
Вообще, с чрутом я загнался, в статье его нет.
Но я тогда не понимаю, в чем смысл использования фпм под разными пользователями - ведь группа у них будет у всех одна? .

 

[AnrDaemon]

У пользователей группа может быть общая, а вот права на файлы могут быть любые. В том числе никакого отношения к группе не имеющие.
Группа сама по себе вообще ничего не даёт, это просто инструмент управления доступом.

P.S.
Кто сказал нет средств? А cgmanager тогда что?

P.P.S.
Создай отдельные профили apparmor для каждого пользователя, будет такая защита, какую хочешь, вместо мамонтячьего чрута.

 

[grigori]

можно nginx добавить в группу www-data, а юзеров не включать, но выставить на их папки 'chgrp -R www-data /path/to; chmod -R g+rx /path/to',
nginx сможет читать все папки, будучи в этой группе, а процессы php - только те, у которых или user совпадает, или в пермиссиях доступ для всех.

если надо ограничивать ресурсы - то докер или виртуалки, чрут не помешает одному процессу засрать i/o на 100%

с чрутом ты будешь долго выгребать проблемы с системными библиотеками - например openssl

 

[Фанат]

можно nginx добавить в группу www-data, а юзеров не включать, но выставить на их папки 'chgrp -R www-data /path/to; chmod -R g+rx /path/to',

Погоди. Но при работе сайта под юзером, вновь созданные (закачанные) все равно будут создаваться без ввв-дата - верно?

Короче, во-первых, я загнался с чрутом.
Это я уже вычитал в другой статье. И решил добавить от себя.
А в той, на которую ссылка вначале, как раз написано, что чрут он не рекомендует.

Тогда остается вопрос.
Я много слышал что пхп-фпм, запускаемый под раздельными юзерами, позволяет увеличить безопасность.
Но в чем заключается эта безопасность?

Только в том, что я теоретически, сам, руками могу выставить на файл 400 - и он будет доступен скриптам сайта, но недоступен другим пользователям?
Ну так для колхоза это не актуально - там никто не будет заморачиваться.

 

[fixxxer]

Я много слышал что пхп-фпм, запускаемый под раздельными юзерами, позволяет увеличить безопасность.
Но в чем заключается эта безопасность?

Ровно в том же, в чем заключается безопасность, когда на сервер по ssh ходит каждый своим пользователем, а не все одним.

(Я, конечно, рассматриваю нормальный случай, а не open_basedir + анально огороженные exec/proc_open и сотоварищи).

Чрут же при этом дополнительно спасает от ситуации, когда два долбоклюя по старой привычке к говнохостам понаставили 777 на папочку uploads своих вордпрессов, и одному из них влили вебшелл.

 

[Фанат]

Ровно в том же, в чем заключается безопасность, когда на сервер по ssh ходит каждый своим пользователем, а не все одним.

Блин, вы меня не путайте.
В случае с шеллом мои файлы по умолчанию недоступны другим пользователям вообще.
В случае с веб-сервером я обязан дать доступ на чтение к моим файлам всему колхозу.

То есть, фпм под юзером защищает нас только от
1. Запись в чужой каталог (поскольку мы не даем доступа на запись кому попало, а пишем только фпм-ом, который под нами)
2. Можем специально выставить права на файл с паролями так, что его никто не прочитает, кроме нас самих.

При этом читать чужие файлы, доступные веб-серверу, мы всё так же можем.

Так?

 

[grigori]

нет, можно сделать авторизацию на php и отдавать через nginx accel-redirect, а напрямую и другим юзерам сервера не отдавать

 

[Фанат]

нет, можно сделать авторизацию на php и отдавать через nginx accel-redirect, а напрямую и другим юзерам сервера не отдавать

ну для некоторых файлов можно, да.

Вообще, если делать приложение с единой точкой входа, то нужниксу надо давать на чтение только её. А остальные вполне можно сделать недоступными.

Что мы имеем в сухом остатке?
Серьезное приложение, которое имеет стратегию безопасности, не будет хоститься в колхозе на вдс-ке.
А для обычных колхозников безопасности не больше, чем для старого доброго колхоза под апачью.

 

[WMix]

Но при работе сайта под юзером, вновь созданные (закачанные) все равно будут создаваться без ввв-дата - верно?

chmod g+s /path

будет выставлять группу на новые филе от группы папки /path

 

[grigori]

Фанат, nginx-у не нужно право на чтение php-скрипта, это не апач.

В колхозе (shared hosting) не будет, а на vds в amazon web service - очень даже.

 

[Фанат]

Фанат, nginx-у не нужно право на чтение php-скрипта, это не апач.

Ага, это уже ближе к истине.
То есть он не проверяет существование файла, а тупо передает урл хендлеру?
Это уже интереснее.
Получается, что пермишен у меня по какой-то другой причине...
Буду разбираться

 

[Фанат]

в колхозе (shared hosting) не будет, а на vds в amazon web service - очень даже

В данном случае колхоз - это shared hosting of my own, на той самой вдс-ке.
А чем он может помочь на амазоне?