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
