Re: чтение чужих файлов: не стоит патчить

Gena Makhomed gmm на csdoc.com
Пн Ноя 28 19:26:45 UTC 2011


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