On Fri, Oct 20, 2017 at 04:58:26PM +0300, Maksim Kulik wrote:

> Нуууу... в таком случае unit и писать не надо. Это ж будет один
> мастер-процесс, который будет работать под рутом и иметь доступ к данным
> вообще всех сайтов. Проблема слегка преувеличена и, если бы все были
> настолько параноидальными в безопасности - мы бы до сих пор не увидели
> систем виртуализации, т.к. во всех таких системах есть тот, кто имеет
> доступ ко всем виртуалкам одновременно и в нем 100% есть ошибки, которые
> потенциально могут позволить получить доступ к нему из виртуальной среды,
> ну а там уже и ко всему серверу.

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

> P.S. Я не утверждаю, что это правильный подход, но ради
> быстродействия/удобства/цены можно в некоторых случаях снизить планку
> безопасности.

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

а вот если их 100500, а молотят в один момент только 10 из них -- то
все уже несколько иначе.

удобство -- вообще отдельный вопрос.

> > Это достаточно самоочевидно для любого, кто немного интересуется
> > безопасностью.
> > Ну и для програмистов эдак начиная примерно с 15+ лет опыта. Но лучше 20+.
> > В общем когда приходит понимание, что программ без ошибок не бывает.
> > Тогда доходит и мысль о том, что общий мастер-процесс на всех должен
> > иметь возможность читать конфиг принадлежащий любому пользователю и
> > перезапускать пул(ы) от любого пользовательского UID, а это уже есть
> > некторая дыра, т.к. он получается должен быть рутовым.
> > В модели отдельного мастера на пользователя он после запуска
> > безвозвратно дропает свои привелегии и эта схема в целом меньше
> > подвержена протечкам.
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >

> _______________________________________________
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru