<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 26.08.2015 13:29, Vasiliy Tolstov
wrote:<br>
</div>
<blockquote
cite="mid:CACaajQv2RgcG+x0FB6V=C09HWLKmdUdXSB4ciPL6zF3SnCHCGQ@mail.gmail.com"
type="cite">
<p dir="ltr"><br>
26 авг. 2015 г. 12:01 пользователь "paperroot" <<a
moz-do-not-send="true" href="mailto:nginx-forum@nginx.us">nginx-forum@nginx.us</a>>
написал:<br>
><br>
> Konstantin Tokarev Wrote:<br>
> -------------------------------------------------------<br>
> > 25.08.2015, 17:37, "paperroot" <<a
moz-do-not-send="true" href="mailto:nginx-forum@nginx.us">nginx-forum@nginx.us</a>>:<br>
> > > Здравствуйте.<br>
> > ><br>
> > > Хочу написать патч, который будет отдавать
контент предварительно<br>
> > > setuid'ившись в системного пользователя
указанного в конфиге<br>
> > virtual_host'a,<br>
> > > для того чтобы обезопасить большое кол-во
независимых проектов от<br>
> > разных<br>
> > > пользователей, работающих на одном мощном
сервере.<br>
> > ><br>
> > > Сделал правку в файле
src/http/modules/ngx_http_static_module.c в<br>
> > функции<br>
> > > ngx_http_static_handler.<br>
> > > Суть правки: делается clone на участок кода:<br>
> > ><br>
> > > setgit(vh_gid);<br>
> > > setuid(vh_uid);<br>
> > > ngx_open_cached_file(clcf->open_file_cache,
&path, &of, r->pool);<br>
> > ><br>
> > > данная правка работает, но имеются проблемы со
сторонними модулями,<br>
> > например<br>
> > > pagespeed.<br>
> > ><br>
> > > Подскажите пожалуйста, где идеалогически
правильнее делать такую<br>
> > правку,<br>
> > > чтобы она дружила с другими модулями, или хотябы
с модулем<br>
> > pagespeed.<br>
> ><br>
> > Мне кажется, что единственный идеологически верный
путь - запускать по<br>
> > отдельной<br>
> > копии nginx для каждого виртуального хоста под
соответствующим<br>
> > пользователем, и<br>
> > проксировать на них запросы с главного Nginx<br>
> ><br>
> > ><br>
> > > Спасибо.<br>
> > ><br>
> > > Posted at Nginx Forum:<br>
> > <a moz-do-not-send="true"
href="http://forum.nginx.org/read.php?21,261237,261237#msg-261237">http://forum.nginx.org/read.php?21,261237,261237#msg-261237</a><br>
> > ><br>
> > > _______________________________________________<br>
> > > nginx-ru mailing list<br>
> > > <a moz-do-not-send="true"
href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
> > > <a moz-do-not-send="true"
href="http://mailman.nginx.org/mailman/listinfo/nginx-ru">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br>
> ><br>
> > --<br>
> > Regards,<br>
> > Konstantin<br>
> ><br>
> > _______________________________________________<br>
> > nginx-ru mailing list<br>
> > <a moz-do-not-send="true"
href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
> > <a moz-do-not-send="true"
href="http://mailman.nginx.org/mailman/listinfo/nginx-ru">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a><br>
><br>
> Да такой вариант тоже рассматривался, но он к сожалению
довольно затратен по<br>
> вычислительным ресурсам и слишком сложный для управления и
сопровождения.<br>
><br>
</p>
<p dir="ltr">Я видел такие решения у некоторых хостингов. Экономия
выходит на спичках, а проблем становиться больше. Накладные
расходы на каждый экземпляр nginx для пользователя
несущественны. Не мучайтесь и не заводите себя в тупик. Сделайте
каждому юзеру по nginx и все.</p>
<p dir="ltr">> Я лишь прошу подсказать "точку входа" для
правки, т.к. чтение кода nginx и<br>
> дебагинг с gdb не дали мне ответа на этот вопрос. Гугление
тоже ничего не<br>
> дало, нету описания архитектуры или схемы обработки
сетевого подключения.<br>
><br>
> Поэтому и решил задать вопрос здесь.<br>
><br>
> Posted at Nginx Forum: <a moz-do-not-send="true"
href="http://forum.nginx.org/read.php?21,261237,261255#msg-261255">http://forum.nginx.org/read.php?21,261237,261255#msg-261255</a><br>
><br>
> _______________________________________________<br>
> nginx-ru mailing list<br>
> <a moz-do-not-send="true" href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
> <a moz-do-not-send="true"
href="http://mailman.nginx.org/mailman/listinfo/nginx-ru">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
nginx-ru mailing list
<a class="moz-txt-link-abbreviated" href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a>
<a class="moz-txt-link-freetext" href="http://mailman.nginx.org/mailman/listinfo/nginx-ru">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></pre>
</blockquote>
Во-первых по поводу архитектуры Nginx, рекомендую взглянуть на книгу
архитектура приложений с открытым исходным кодом:<br>
<a class="moz-txt-link-freetext" href="http://rus-linux.net/MyLDP/BOOKS/Architecture-Open-Source-Applications/Vol-2/14-nginx-1.html">http://rus-linux.net/MyLDP/BOOKS/Architecture-Open-Source-Applications/Vol-2/14-nginx-1.html</a><br>
<br>
Там отдельная глава, посвященная nginx и принципам его работы.<br>
<br>
Во-вторых при реализации подобного решения нужно учитывать принципы
работы nginx и его модель обработки соединений(epoll). Если в апаче
есть мод itk и там для каждого соединения делается fork, внутри
которого можно делать смену uid и это ограничивает для всяких PHP
скриптов возможность записи в другие директории, то в nginx висит
фиксированное число workers, которые обрабатывают все connect'ы.
Даже если сделать setuid перед обработкой статики, а потом выходить,
то никакого увеличения безопасности не будет. Уже не говорю про
накладные расходы.<br>
<br>
По поводу несколько экземпляров nginx. Это тоже не вариант решения
вопроса, так как если у вас два-три клиента, то это может и будет
экономия на спичках, но если на одном сервере тысячи клиентов, то
такое решение уже совсем не подходит.<br>
</body>
</html>