ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
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


 




Copyright © Lexa Software, 1996-2009.