Re: Хочу написать патч

[navern]

On 26.08.2015 13:29, Vasiliy Tolstov wrote:
>
>
> 26 авг. 2015 г. 12:01 пользователь "paperroot" <nginx-forum на nginx.us 
> <mailto:nginx-forum на nginx.us>> написал:
> >
> > Konstantin Tokarev Wrote:
> > -------------------------------------------------------
> > > 25.08.2015, 17:37, "paperroot" <nginx-forum на nginx.us 
> <mailto:nginx-forum на nginx.us>>:
> > > > Здравствуйте.
> > > >
> > > > Хочу написать патч, который будет отдавать контент предварительно
> > > > setuid'ившись в системного пользователя указанного в конфиге
> > > virtual_host'a,
> > > > для того чтобы обезопасить большое кол-во независимых проектов от
> > > разных
> > > > пользователей, работающих на одном мощном сервере.
> > > >
> > > > Сделал правку в файле src/http/modules/ngx_http_static_module.c в
> > > функции
> > > > ngx_http_static_handler.
> > > > Суть правки: делается clone на участок кода:
> > > >
> > > > setgit(vh_gid);
> > > > setuid(vh_uid);
> > > > ngx_open_cached_file(clcf->open_file_cache, &path, &of, r->pool);
> > > >
> > > > данная правка работает, но имеются проблемы со сторонними модулями,
> > > например
> > > > pagespeed.
> > > >
> > > > Подскажите пожалуйста, где идеалогически правильнее делать такую
> > > правку,
> > > > чтобы она дружила с другими модулями, или хотябы с модулем
> > > pagespeed.
> > >
> > > Мне кажется, что единственный идеологически верный путь - запускать по
> > > отдельной
> > > копии nginx для каждого виртуального хоста под соответствующим
> > > пользователем, и
> > > проксировать на них запросы с главного Nginx
> > >
> > > >
> > > > Спасибо.
> > > >
> > > > Posted at Nginx Forum:
> > > http://forum.nginx.org/read.php?21,261237,261237#msg-261237
> > > >
> > > > _______________________________________________
> > > > nginx-ru mailing list
> > > > nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
> > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> > >
> > > --
> > > Regards,
> > > Konstantin
> > >
> > > _______________________________________________
> > > nginx-ru mailing list
> > > nginx-ru на nginx.org <mailto:nginx-ru на nginx.org>
> > > http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >
> > Да такой вариант тоже рассматривался, но он к сожалению довольно 
> затратен по
> > вычислительным ресурсам и слишком сложный для управления и 
> сопровождения.
> >
>
> Я видел такие решения у некоторых хостингов. Экономия выходит на 
> спичках, а проблем становиться больше. Накладные расходы на каждый 
> экземпляр nginx для пользователя несущественны. Не мучайтесь и не 
> заводите себя в тупик. Сделайте каждому юзеру по nginx и все.
>
> > Я лишь прошу подсказать "точку входа" для правки, т.к. чтение кода 
> nginx и
> > дебагинг с gdb не дали мне ответа на этот вопрос. Гугление тоже 
> ничего не
> > дало, нету описания архитектуры или схемы обработки сетевого 
> подключения.
> >
> > Поэтому и решил задать вопрос здесь.
> >
> > Posted at Nginx Forum: 
> http://forum.nginx.org/read.php?21,261237,261255#msg-261255
> >
> > _______________________________________________
> > nginx-ru mailing list
> > nginx-ru на nginx.org <mailto: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, рекомендую взглянуть на книгу 
архитектура приложений с открытым исходным кодом:
http://rus-linux.net/MyLDP/BOOKS/Architecture-Open-Source-Applications/Vol-2/14-nginx-1.html

Там отдельная глава, посвященная nginx и принципам его работы.

Во-вторых при реализации подобного решения нужно учитывать принципы 
работы nginx и его модель обработки соединений(epoll). Если в апаче есть 
мод itk и там для каждого соединения делается fork, внутри которого 
можно делать смену uid и это ограничивает для всяких PHP скриптов 
возможность записи в другие директории, то в nginx висит фиксированное 
число workers, которые обрабатывают все connect'ы. Даже если сделать 
setuid перед обработкой статики, а потом выходить, то никакого 
увеличения безопасности не будет. Уже не говорю про накладные расходы.

По поводу несколько экземпляров nginx. Это тоже не вариант решения 
вопроса, так как если у вас два-три клиента, то это может и будет 
экономия на спичках, но если на одном сервере тысячи клиентов, то такое 
решение уже совсем не подходит.
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20150826/4b6c4dfa/attachment.html>