Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: чтение чужих файлов: не стоит патчить
- To: nginx-ru@xxxxxxxxx
- Subject: Re: чтение чужих файлов: не стоит патчить
- From: Gena Makhomed <gmm@xxxxxxxxx>
- Date: Mon, 28 Nov 2011 21:26:45 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=csdoc.com; s=dkim; t=1322508416; bh=G25K6I0dMcmO9IHIToh36+1VrgI5B1QfWofIWAzzkO8=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=V4ZJ0ogNR4+BtSAQ2ICHcaWfKuondVo7Wnij6uwBtc+pv5t/knyBtes2wHM0lhsxQ l4QkyXPZRyyvGkNTR4yA37FWG35wudD1Ztd9eZcWYF8baDcnB+TPziX1ImCapzynol qG4dezSgtby0gAD5Lv/fEPzfFBYT6DGaIJtdesys=
- In-reply-to: <20111128175843.GC5363@xxxxxxxxxxxxxxxxxxxx>
- References: <20111128175843.GC5363@xxxxxxxxxxxxxxxxxxxx>
On 28.11.2011 19:58, Peter Vereshagin wrote:
все остальные "удобные пути" можно закрыть корректной настройкой apache,
FollowSymLinks, SymLinksIfOwnerMatch, php_admin_value open_basedir
и корректной настройкой прав доступа к каталогам пользователей.
Чересчур много условий. Я б рекомендовал сказать --- и отрезать:
- юзерам чтобы не выкладывали коды своих банковских карточек (& etc. ) на
шареный виртхостинг
проблема в том, что таким образом любой сайт на shared hosting`е
может быть легко/тривиально превращен в источник внедоносного кода,
вирусов/троянов и т.п. - в самых тяжелых случаях пользователю вообще
не надо ничего запускать, достаточно просто открыть сайт в браузере,
и все - его локальная машина уже будет заражена вирусами/троянами,
и уже у пользователя будут воровать коды банковских карточек и т.п.
- девелоперам nginx что уродливое (No)FollowSymlinks(IfOwnerMatch) не
нужно.
уродливое не нужно. нужно нормальное. даже опция для открытия файлов
с флагом O_NOFOLLOW устранит 99% проблем, если не больше.
В перспективе --- ждать, пока в o/s появятся nosymfollowifownernotmatch для
mount.
этого ждать можно вечно. проще будет сделать еще один форк nginx.
А вообще, шареный хостинг не нужен, есть облачные платформы
какой-то беспредметный разговор получается.
если лично Вам shared hosting не нужен - не пользуйтесь, в чем проблема?
$shared_hosting === $apache_httpd
много кода на PHP, и много программистов,
которые зарабатывают созданием сайтов на PHP.
и как результат - много клиентов которые хотят
сайт на PHP и чтобы его потом можно было
дешево разместить в интернете.
пока что конкурентов PHP нет и не наблюдается
в плане возможности максимально плотно упаковать
разные виртуальные хосты на один физический сервер.
RFC на запуск php-демона следующим образом: линковка бинарников, в дальнейшем
форки с раздельными ивент-лупами под разными uid'ами на разные чруты и
порты/локалсокеты ( per uid, например ). Кол-во форков per uid
можно сделать переменным, дабы адаптивно менялось под slashdotting-нагрузки
per uid. При этом проблема объединения persistent-кеша для одинаковых
php-исходников у разных uid может быть решена посредством отдельного
мемкеш-лайк демона, хранящего пары вида "чексумма php-блоба - скомпилированный
опкод". Хороший способ сэкономить толпу ресурсов и таки разнести php-демоны по
uid'ам и chroot'ам.
в результате - для каждого виртуального хоста всегда будет активен как
минимум один PHP-демон, который будет занимать и память и процессор.
использование ресурсов гораздо выше по сравнению с shared hosting`ом.
тем более, что очень много сайтов просто не будут нормально работать
без .htaccess файла и директив апачевского mod_rewrite внутри.
кроме того, вопрос был не про PHP, вопрос был про отдачу статики.
тут ведь кроме отдельного экземпляра PHP для каждого пользователя -
надо будет внутри chroot`ов запускать и по отдельному экземпляру nginx.
и это уже тоже по определению совсем не shared hosting будет,
что находится очень далеко за пределамы обсуждаемой сейчас темы
(nginx + возможность прочитать чужие файлы на shared hosting).
--
Best regards,
Gena
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru
|