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

[fixxxer]

Если уж очень упороться, можно вообще php статически собрать со всеми либами. Хотя я все равно не понимаю, какие особые сложности пройтись рекурсивно ldd.

 

[grigori]

да хрен там, CA для openssl все-равно в чруте собирать

 

[fixxxer]

Зачем? Я тебя не понимаю Можно пример?

 

[grigori]

у нас была авторизация по самоподписанному сертификату со своим CA. впрочем, это исключение

 

[MiksIr]

Вопрос "а нафига" остается открытым. (про chroot)

 

[fixxxer]

у нас была авторизация по самоподписанному сертификату со своим CA

Ну, допустим. И?

 

[grigori]

в чруте нужны .so от openssl, индивидуальный openssl.conf, пробороска /dev/urandom, я уже все не помню

 

[fixxxer]

Они и не в чруте лишними не будут Ну короче все стандартно, я думал особенное что

 

[AnrDaemon]

Пока вы тут пережёвываете чрут, я уже запилил пару скриптов на запуск двух php-fpm и пару профилей apparmor для них.

 

[fixxxer]

А я паппетом докеры с fpm поднимаю, и что =)

 

[hell0w0rd]

Вот тут докер уже несколько раз упоминался. Он же вроде и сделан для таких задач, чтобы ни о каких chroot, куче юзеров и тп не думать. Создал контейнер - че хочешь туда ставь, порты прокидывай и используй.

 

[fixxxer]

Ну не на @Фанат'овской виртуалке за 5 баксов же. Каждой задаче свое решение.

 

[hell0w0rd]

@fixxxer, а почему нет? Если нужно всего по контейнеру на приложение. Базу можно прокинуть из хоста, тут уже каждому по пользователю, на пример. Или контейнеры не на столько легковесны?

 

[fixxxer]

Ну это знаешь, как на symfony писать hello world. Можно, но зачем?

 

[Активист]

Разные PHP-FPM (на каждого пользователя).
При этом права сделаны так

root@serv001:~# groups www-data
www-data : www-data
root@serv001:~# groups user
user : user mgrsecure
root@serv001:~# ls -lash /var/www
итого 692K
4,0K drwx--x--x 90 www-data mgrsecure 4,0K Авг 11 11:56 .
4,0K drwxr-xr-x 16 root root 4,0K Июн 29 2014 ..
4,0K dr-x-----x 3 user mgrsecure 4,0K Сен 26 2013 user
root@serv001:~# cd ~user
root@serv001:/var/www/user/data# sudo -u www-data ls
ls: невозможно открыть каталог .: Отказано в доступе
/var/www/user/data# sudo -u www-data ls www/xxx.ru/
...

Nginx все равно cgi не выполняет (только через менеджеры процессов), так что, нечего бояться. На апач ставится suexec

 

[AnrDaemon]

@fixxxer, а почему нет? Если нужно всего по контейнеру на приложение. Базу можно прокинуть из хоста, тут уже каждому по пользователю, на пример. Или контейнеры не на столько легковесны?

Зависит от настроек. Можно overlayfs замутить, будет по сути "glorified chroot". Но это действительно сильно более заморочно, чем взять шаблонный профиль apparmor и подрихтовать под себя. При том что безопасность в контейнерах тем же самым apparmor обеспечивается (в том числе).

 

[Фанат]

ls: невозможно открыть каталог .: Отказано в доступе
/var/www/user/data# sudo -u www-data ls www/xxx.ru/

Погоди, а статика?
А как тогда нжинкс будет статику отдавать, если он в каталог пользователя зайти не может?

 

[AnrDaemon]

У sudo кроме -u есть ещё и -g.
@Фанат, при правильной настройке - сможет зайти.

 

[Активист]

Погоди, а статика?
А как тогда нжинкс будет статику отдавать, если он в каталог пользователя зайти не может?

Разрешить глубже по вложенности на чтение

 

[Фанат]

Разрешить глубже по вложенности на чтение

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

Чтобы разрешить на чтение, надо разрешить все каталоги в цепочке на выполнение. поскольку исполнение на каталоге означает разрешение на переход в него.
Если разрешать на выполнение, то кто угодно сможет зайти в каталог.
И плюс добавить чтение, то кто угодно (в той же самой группе) сможет прочитать.
В чём же тогда защита будет?

Собственно, меня ведь интересует не решение академической проблемы "как дать кому-то доступ, а кому-то не дать", а практической "сетап веб-аервера, который реализует преимущество запуска пыхи под своим пользователем"