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

[Peter Vereshagin <peter@xxxxxxxxxxxxxx>]

Hello.

2011/11/28 20:03:02 +0000 nginx-ru-request@xxxxxxxxx => To nginx-ru@xxxxxxxxx :

> проблема в том, что таким образом любой сайт на shared hosting`е
> может быть легко/тривиально превращен в источник внедоносного кода,
> вирусов/троянов и т.п. - в самых тяжелых случаях пользователю вообще
> не надо ничего запускать, достаточно просто открыть сайт в браузере,
> и все - его локальная машина уже будет заражена вирусами/троянами,
> и уже у пользователя будут воровать коды банковских карточек и т.п.

Как будто без Follow Symlinks If Owner Match на shared hosting и так нельзя
положить источник ВНЕ ДОНОСНОГО кода... (=

> >      - девелоперам nginx что уродливое (No)FollowSymlinks(IfOwnerMatch) не 
> > нужно.
> уродливое не нужно. нужно нормальное. даже опция для открытия файлов
> с флагом O_NOFOLLOW устранит 99% проблем, если не больше.

Чересчур иллюзорно.
После такого "устранения" оставшийся 1% становится всеми 100%, это так радужно. 
(=
а где написано что мол nginx предназначено для замены apache на shared hostings?

> > В перспективе --- ждать, пока в o/s  появятся  nosymfollowifownernotmatch  
> > для
> > mount.
> этого ждать можно вечно. проще будет сделать еще один форк nginx.

Бесперспективно.

> > А вообще, шареный хостинг не нужен, есть облачные платформы
> какой-то беспредметный разговор получается.

хотите предметы --- скипайте квоту аккуратнее. Что там про панельки было?
Ключевое слово --- "в перспективе".

> если лично Вам shared hosting не нужен - не пользуйтесь, в чем проблема?

спасибо за разрешение. 

> > $shared_hosting === $apache_httpd
> пока что конкурентов PHP нет и не наблюдается

не наблюдается != нет

> в плане возможности максимально плотно упаковать
> разные виртуальные хосты на один физический сервер.

выбор технологии (PHP или не PHP) как может быть связан с параметром 'отношение 
кол-ва доменов per сервер'?
а на парковках этот параметр ещё больше, и что? там тоже в наличии корреляция?
и вообще, физические сервера не нужны, есть облака, рекомендую. (=

> > RFC на запуск php-демона следующим образом: линковка бинарников, в  
> > дальнейшем
> > форки с раздельными  ивент-лупами  под  разными  uid'ами  на  разные  чруты 
> >  и
> > порты/локалсокеты  (  per  uid,   например   ).    Кол-во   форков   per   
> > uid
> > можно сделать переменным, дабы адаптивно  менялось  под  
> > slashdotting-нагрузки
> > per  uid.   При  этом  проблема  объединения  persistent-кеша  для  
> > одинаковых
> > php-исходников  у  разных  uid  может  быть  решена   посредством   
> > отдельного
> > мемкеш-лайк демона, хранящего пары вида "чексумма php-блоба - 
> > скомпилированный
> > опкод". Хороший способ сэкономить толпу ресурсов и таки разнести php-демоны 
> > по
> > uid'ам и chroot'ам.
> 
> в результате - для каждого виртуального хоста всегда будет активен как 
> минимум один PHP-демон, который будет занимать и память

Copy On Write уже отменили?

> и процессор.

ивент-лупа преимущественно в состоянии ожидания? Вы делаете мне всё смешнее.

> использование ресурсов гораздо выше по сравнению с shared hosting`ом.
> тем более, что очень много сайтов просто не будут нормально работать
> без .htaccess файла и директив апачевского mod_rewrite внутри.

А ещё mod_access и всех mod_*. Welcome back into the future. Вы там может уже
apache3 изобрели а я и не знаю? (=

> кроме того, вопрос был не про PHP, вопрос был про отдачу статики.

Однако, про PHP здесь где-то было.
а где написано, что мол nginx задуман для раздачи статики с shared hostings?

> тут ведь кроме отдельного экземпляра PHP для каждого пользователя -
> надо будет внутри chroot`ов запускать и по отдельному экземпляру nginx.

а они, вроде, всё равно мапятся все в один участок памяти по типу memory
mapping, нет? если бинарники все в одних и тех же inodes сидят.

> и это уже тоже по определению совсем не shared hosting будет,
> что находится очень далеко за пределамы обсуждаемой сейчас темы
> (nginx + возможность прочитать чужие файлы на shared hosting).

в этих ваших  shared_hosting  ради  кол-ва  абонов  кол-во  whistles  &  bells
настолько велико, что устранять саму возможность всё равно бесполезно.   Да  и
незачем, ведь там всё равно всё  выложено  в  публичный  доступ.   Или  кто-то
забывает сей пункт вложить быдлоюзеру (кто ж ещё в наши дни пользует  заведомо
устаревшую услугу шареного хостинга) на подпись в SA?

--
Peter Vereshagin <peter@xxxxxxxxxxxxxx> (http://vereshagin.org) pgp: A0E26627 

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru