Перейти к контенту
  • 0

Чем опасен shared хостинг


Вопрос

  • Ответы 73
  • Создана
  • Последний ответ

Лучшие авторы в этом вопросе

Лучшие авторы в этом вопросе

Рекомендуемые сообщения

  • 0

;):) :) Никак. Из того, что ваши домены посажены в "песочницу" (sandbox) и вы никого не видите, не следует, что вашими файлами не любуются кракеры из соседних сайтов. Если Алиса ест яблоко, это не значит, что яблоко ест Алису. :D

 

Повторюсь: типичная провайдерская машина - 100-200 пользователей на 2-4 IP. Чтобы отключить safe mode, но при этом оставить пользователя в "песочнице", нужно:

1. Выделить ему адрес IP (деньги!)

2. Запустить на этом адресе отдельную Апачу (расход оперативной памяти!)

3. Завести для этой Апачи дополнительного пользователя типа petrov_apache, создать индивидуальные конфиги и т.п. (расходы на администрирование!).

 

А пользователь платить не хочет, он хочет за свои 5 баксов в месяц иметь выключенный safe mode, из-за которого не ставится его интернет-магазин, любимый форум, веб-альбом и т.п. При этом он не имеет понятия ни о Юниксе, ни о PHP, и засыпает службу поддержки письмами. И уходить к другому хостеру он не хочет (потому как лень) и пишет истеричные письма на провайдерские форумы и т.п. - дескать, меня не предупредили, что у вас safe mode, вот у других, хороших, провайдеров, никакого safe mode нет в помине. А хостер не имеет юридического права в одностороннем порядке расторгнуть договор с таким народным мстителем... Знаете, чем это обычно заканчивается? Тем, что товарищу прописывают в конфиг сайта safe mode off. :) И сколько таких товарищей с отключенным safe mode - через год не помнит толком никто.

 

И самое забавное - хостер НИЧЕМ не рискует. Потому что взлом вашего форума через локальную файловую систему доказать НЕВОЗМОЖНО, в логах Апачи ничего подозрительного не остается. Если бы кракеры не стали хвастаться перед вами стянутой базой, вы бы ничего и не узнали. Поэтому у абсолютного большинства российских провайдеров safe mode выключен ВООБЩЕ, т.к. для хостера геморроя от включенного safe mode будет намного больше, чем от отключенного. Для 99% рядовых пользователей safe mode - не благо, а зловредное изобретение хостеров, чтобы наделать проблем при установке скриптов и развести пользователей на деньги для его отключения.

 

Извините за пространный текст, но говорю только о реальном личном опыте.

 

Из конкретных советов:

 

1. Бегите с хостинга, где вас уже подломали. Вы что думаете, админ у хостера будет заниматься вопросом, кто вас подломал? Да на фиг это ему нужно. Ведь на хостинге это ведь никак не отражается. Настрочит отписку или сделает вид, что ничего не произошло.

 

2. На новый хостинг берите только базу данных, а все остальное ставьте с нуля (стандартная схема действий при взломе).

 

3. Выбирайте хостинг, где нет "пробных периодов", анонимной оплаты через вебмани и т.п. - т.е. где хостинг максимально персонализирован, где пользователю нужно лично явиться в офис с паспортом, прежде чем он получит свой логин/пароль. Поэтому не советую дешевые зарубежные хостинги - там часто помойка гораздо хуже, чем у российских провайдеров.

 

4. Все-таки выбирайте хостинг с отдельной Апачей. Я вот навскидку зашел на сайт Каравана - у них за 10 баксов в месяц уже предоставляется отдельная Апача с конфигом, перезапуском и т.п. Это что, дорого для личного спокойствия??

 

А вообще лучше по таким вопросам пишите мне в личку.

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Как интересно... Вот есть у меня шаред хостинг... Тысяча сайтов на сервере помимо моих. И что, вы утверждаете что права 400 на нужные файлы меня не спасут? :D
Ссылка на комментарий
Поделиться на других сайтах

  • 0
Как интересно... Вот есть у меня шаред хостинг... Тысяча сайтов на сервере помимо моих. И что, вы утверждаете что права 400 на нужные файлы меня не спасут? ;)

400 - это право только владельца на чтение. И кто же у вас владелец? Если вы - то apache этот файл просто не увидит. Если apache - то его не увидите вы, зато увидят все, кто запускает скрипты под пользователем apache. :D

 

Файловая система Юникса создавалась задолго до Интернета и публичные демоны в этой концепции не предполагались. Когда появились httpd/ftpd/maild, им начали давать права доступа либо через смену пользователя, либо через биты группового доступа. Apache + PHP получает права через групповой доступ, т.е. на файлы в public_html/ выставляются права 640 или 660, владелец username, группа apache.

 

Safe mode по умолчанию предполагает ДОПОЛНИТЕЛЬНУЮ проверку username, и если он не совпадает с владельцем скрипта - в доступе отказывается.

 

Делаются попытки давать доступ по второму варианту - через смену пользователя, наподобие ftp. Во-первых, можно запускать php как скрипт. Во-вторых, есть модуль suphp. Оба варианта в промышленном окружении не живут, т.к. жрут кучу ресурсов.

 

Или у вас есть другие варианты?

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Спасибо, почти убедили. Прямые руки решают.
Ссылка на комментарий
Поделиться на других сайтах

  • 0
Как интересно... Вот есть у меня шаред хостинг... Тысяча сайтов на сервере помимо моих. И что, вы утверждаете что права 400 на нужные файлы меня не спасут? ;)

400 - это право только владельца на чтение. И кто же у вас владелец? Если вы - то apache этот файл просто не увидит. Если apache - то его не увидите вы, зато увидят все, кто запускает скрипты под пользователем apache. :D

 

Файловая система Юникса создавалась задолго до Интернета и публичные демоны в этой концепции не предполагались. Когда появились httpd/ftpd/maild, им начали давать права доступа либо через смену пользователя, либо через биты группового доступа. Apache + PHP получает права через групповой доступ, т.е. на файлы в public_html/ выставляются права 640 или 660, владелец username, группа apache.

 

Safe mode по умолчанию предполагает ДОПОЛНИТЕЛЬНУЮ проверку username, и если он не совпадает с владельцем скрипта - в доступе отказывается.

 

Делаются попытки давать доступ по второму варианту - через смену пользователя, наподобие ftp. Во-первых, можно запускать php как скрипт. Во-вторых, есть модуль suphp. Оба варианта в промышленном окружении не живут, т.к. жрут кучу ресурсов.

 

Или у вас есть другие варианты?

это почему же не живут? вы нам тут про какие-то "левые" хостинги сообщаете, в которых вам удалось поработать. suphp на многих хостингах очень даже живет. про окружение open_basedir если честно нелепость какая-то. если руки растут правильно - он спасает.

Изменено пользователем G*g
Ссылка на комментарий
Поделиться на других сайтах

  • 0

G*g, alexei1966

Господа, вы уверены, что хирургам следует обсуждать инструментарий в присутствие пациента? :D

Ссылка на комментарий
Поделиться на других сайтах

  • 0
G*g, alexei1966

Господа, вы уверены, что хирургам следует обсуждать инструментарий в присутствие пациента? :D

Ой, дорогой FatCat - не надо этого делать, вы правы! Правда, вся эта ветка показала, что даже специалисты по php недостаточно знакомы с некоторыми реалиями Юникса. И хостинга. :) Я ведь в основном сижу на форумах сисадминов - там вот эта ситуация с PHP регулярно подымается новичками: да не может быть! - Может, может. - А вот есть лекарство! - А ты попробуй на загруженном хостинге. ;)

 

Насчет suphp - ну вот, с ходу относительно свежая статейка:

http://blog.stuartherbert.com/php/2008/01/...-shared-server/

 

Производительность suphp оказалась по элементарному тесту в 25 раз хуже, чем у обычного php. Правда, suexec еще хуже. Для экспериментов в лаборатории подойдет, для промышленного хостинга - нет. Потому что при высокой нагрузке suphp еще и падает вместе с Апачей.

 

Есть сборка 2-й Апачи MPM Worker, которая позволяет запускать каждый виртуальный хост под своим пользователем. Я эту сборку мучил пару лет назад - падала от малейшего чиха. Сами разработчики предупреждают: она не для промышленного использования.

 

И дело тут вовсе не в кривых руках разработчиков, а в самой архитектуре ядра. Потому что динамическое переключение на другого пользователя по определению жрет немыслимо ресурсов процессора. :) Точка. Правда, слышал, что какие-то энтузиасты делают специальные сборки ядер, заточенные исключительно под хостинг Апачи, но пока это, скорее, экзотика и чистый эксперимент.

 

Насчет защиты с помощью open_basedir. Если safe mode выключен - на полную катушку работают функции exec, system и тп. (эксплойты приводить не буду - это очевидно). Если safe_mode включен - а зачем тогда open_basedir? :)

 

В общем, не случайно в тарифных сетках очень многих провайдеров сейчас значатся тарифы с отдельной Апачей на отдельном IP. Причем востребованность их растет, цены падают. И главный смысл перехода на эти тарифы - не играться с конфигами, а сесть в "песочницу", чтобы другие не достали.

 

И еще раз поддерживаю предложение - давайте обсуждать такие вещи в личке.

 

У меня другая просьба к уважаемым господам Sannis, FatCat и другим старожилам форума. Раз уж у нас начался диалог... Я наткнулся на глобальный баг в календарной системе IPB 2.3. Смысл: если при вводе события указать время суток, оно потом начинает скакать, как заяц. Причем этот баг есть и в версии 3.0, над ним явно работали, но все равно проблема осталась:

http://www.ibresource.ru/forums/index.php?showtopic=57123

http://www.ibresource.ru/forums/index.php?showtopic=53875

 

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

Ссылка на комментарий
Поделиться на других сайтах

  • 0

я все таки дополню. open_basedir и нужно использовать с отключением исполняемых функций, иначе смысла в этом нет. это, на мой взгляд, и новичку должно быть понятно, как и указание своих временных директорий, для хранения сессий и прочей ерунды.

а safe_mode на самом деле вещь бесполезная.

 

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

Изменено пользователем G*g
Ссылка на комментарий
Поделиться на других сайтах

  • 0
Если safe mode выключен - на полную катушку работают функции exec, system и тп. (эксплойты приводить не буду - это очевидно). Если safe_mode включен - а зачем тогда open_basedir?
open_basedir и нужно использовать с отключением исполняемых функций, иначе смысла в этом нет. это, на мой взгляд, и новичку должно быть понятно, как и указание своих временных директорий, для хранения сессий и прочей ерунды.

Вот-вот. Мне видимо, повезло, что безопасный режим выключен, а exeс не доступен? Лучше уж не говорить, какие все плохие, а админы глупые, а назвали хостинги, которыми лучше не пользоваться. От этого была бы всем польза :D

Ссылка на комментарий
Поделиться на других сайтах

  • 0

почему же не продолжать эту тему?

весьма много полезной информации, ее потом можно будет переименовать и кинуть в какой-нибудь умный раздел

Ссылка на комментарий
Поделиться на других сайтах

  • 0

У меня тогда возник вопрос в ту же тему защиты.

Имеет ли какое-то отношение к php как модуль апачи, как модуль сиджиай и как модуль фаст сиджиай?

 

Есть ли вариант safe_mode не включать, а поставить php модуль как сиджиай или фаст сиджиай?

 

Можете прокомментировать сам факт существования разный модулей php и чем это хорошо/плохо в целом и в плане "защиты от соседей" в частности?

Ссылка на комментарий
Поделиться на других сайтах

  • 0

:) Выдался свободный вечер. Давайте, попробую ответить всем интересующимся в форме вопросов и ответов. Которые, впрочем, следует воспринимать с известной долей юмора. Тем более что наступило 1-е апреля. ;)

 

*** Почему вы считаете, что виртуальный совместный (shared) хостинг небезопасен с точки зрения секретности данных?

 

При этом виде хостинга один и тот же демон запущенного веб-сервера обслуживает несколько виртуальных хостов. В реальности их число доходит до 100-200. Программы (скрипты, сценарии), которые запускаются от имени веб-сервера на любом виртуальном хосте, по умолчанию получают права веб-сервера. То есть - если Апача может считать файл с паролями к базе данных в вашем каталоге, этот файл может точно так же прочитать скриптом любой пользователь этого хостинга. При этом в логах не останется никаких следов.

 

Детали. В классическом Юниксе на файл предусмотрено 3 группы прав: User (владелец), Group (группа), Others (Прочие). Веб-сервер получает доступ к файлам через права группы, потому что других способов при совместном хостинге, к сожалению, просто нет (другие способы возможны только на более современных файловых системах, в частности, NTFS).

 

Обычно делается отдельный каталог, например, public_html, в котором создаются подкаталоги пользователей с правами 2750:

 

public_html/ivanov drwxr-s--- ivanov.apache

public_html/petrov drwxr-s--- petrov.apache

public_html/sidorov drwxr-s--- sidorov.apache

 

Аpache получает права на каталоги с дополнительным битом setGID, поэтому все файлы и каталоги, которые создаются средствами веб-сервера, будут также принадлежать группе apache и apache сможет с ними работать. Такой способ организации файлов и каталогов иногда называют способом BSD.

 

Таким образом, пользователь ivanov, зайдя по FTP, увидит содержимое только своего каталога, на который он имеет полные права, и сможет выгрузить туда нужные файлы, а к соседям petrov, sidorov и тп. зайти не сможет.

 

В то же время пользователь apache по умолчанию имеет права на чтение всех подкаталогов public_html/ - он сможет прочитать любые файлы в этих подкаталогах, однако ничего записать туда не сможет. Если веб-серверу нужно что-то писать, то на нужные каталоги следует вручную установить права 2770. Кстати, эта операция проделывается при каждой установке IPB.

 

Поэтому для чтения ваших файлов с конфиденциальной информацией злоумышленнику бывает достаточно взломать любой из 100-200 виртуальных хостов, или даже просто купить на время хостинг - стоит это недорого, к тому же многие интернет-провайдеры предлагают бесплатный тестовый период или гарантию возврата денег.

 

*** Какой ужас! И что же можно сделать, чтобы скрипты PHP не могли "ходить к соседям"?

 

Существует два принципиально разных способа.

 

Первый - ограничивать права внутри самого mod_php. Это safe mode и open_basedir. При safe mode по умолчанию проверяются права владельца на скрипт и сравниваются с правами владельца файла, который этот скрипт пытается открыть. Например, если скрипт из каталога petrov пытается открыть файл в каталоге ivanov, в доступе будет отказано. Также может быть ограничен список программ, которые могут быть запущены скриптами php. При open_basedir ограничивается "сверху" каталог, внутри которого может открывать файлы скрипт данного пользователя.

 

Недостатки safe mode:

1. Целый ряд сложных скриптов, написанных на PHP, перестает работать.

2. Возможно создание файлов, которые сам пользователь не сможет удалить.

3. Адекватная настройка safe mode достаточна сложна для хостинг-провайдера: запретишь слишком много - будут недовольны пользователи, запретишь слишком мало - а зачем оно тогда надо?

4. Поддержка safe mode после долгих дебатов была полностью удалена из PHP 6. Главный аргумент: порождает в пользователях ложное чувство, что PHP работает "безопасно", а это не так. Читать здесь:

http://www.php.net/~derick/meeting-notes.html

 

Хорошо также сказано в мануале PHP:

Chapter 42. Safe Mode

The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now.

 

Недостатки open_basedir:

Не ограничивает функции exec(), system() и другие. Без safe mode директива почти бесполезна, в частности, прекрасно сработает такая строчка:

 

system('cat /path_to/conf_global.php')

 

Второй способ - динамически менять права веб-сервера на права пользователя в момент исполнения скрипта.

 

Наиболее известные реализации - suphp и запуск PHP в виде модуля CGI.

 

Недостаток: чудовищный расход ресурсов процессора. Производительность падает не в 2-3, а в 20-30 раз. Это связано с архитектурой Юникса, в которой никогда не предполагалось, что переключение контекста пользователя будет производиться динамически, для промышленных задач. Такие сложные скрипты, как IPB, OpenCommerce или Bitrix могут запросто повесить машину.

 

*** А если хорошо отладить safe mode? Решит ли это проблему совместного хостинга?

 

Ладно, пускай вы отладили safe mode. Но кроме php, существует еще целый ряд языков и интерфейсов. Это:

 

1. SSI (Server-Side Includes), появившийся в незапамятные времена. Если в ваш хостинг-план входит "поддержка shtml" - знайте, это оно и есть. SSI запускаются с правами веб-сервера и содержат замечательную инструкцию exec. Ее надо отключать (IncludesNoExec).

 

2. CGI (Common Gateway Interface) - общее название для скриптов на любом языке, которые читают со stdin и отдают поток на stdout. Чаще всего скрипты пишутся на Perl, Python, Tcl/Tk, Java, на Си и языке командного интерпретатора. По умолчанию все эти скрипты также запускаются с правами веб-сервера.

 

Наиболее распространенный способ решить проблему в CGI - запуск под suexec.

 

Недостаток: снова - чудовищный расход ресурсов и падение производительности во много раз. Для увеличения производительности, в частности, ставят такую среду, как mod_perl. Однако mod_perl по определению не способен к переключению контекстов и всегда выполняется с правами веб-сервера (говорят, что-то придумали в 2-й Апаче и 2-м mod_perl, но до промышленного использования когда еще дойдет).

 

*** И все-таки - если хостер все сделал правильно, можно ли быть уверенным в конфиденциальности моих данных на совместном хостинге?

 

Послушайте, любезный, я повторю еще раз: по умолчанию любой из 100-200 соседей по хостингу может забраться в веб-каталог к вам, как в свой собственный, потому что такова архитектура совместного виртуального хостинга. Чтобы клиенты не лазили друг к другу, администратор хостера должен индивидуально настроить ограничения для каждого языка и для каждой среды исполнения - отдельно для PHP, отдельно для SSI, отдельно для CGI, отдельно для mod_perl и т.п.. Это требует высокой квалификации и большого опыта администраторов. А можно и ничего не настраивать, при этом вопросов в техподдержку пользователи будут писать меньше. И сервера будут работать быстрее. А главное - ответственности хостера за взлом ваших данных ни-ка-кой. Ни юридической, ни моральной.

 

Добавьте к этому специфические дыры, которые могут быть в библиотеках любого скриптового языка. Например, не так давно прошла информация об эксплойте в PHP конкретных версий, который позволял отправлять на почту произвольный текстовый файл. Вы что, собираетесь следить за всеми библиотеками, которые стоят на хостинге?..

 

*** Я не верю, что совместный хостинг такой дырявый - вот мой сайт за много лет не сломали ни разу!

 

Как известно, оптимист - плохо информированный пессимист. Скорее всего, по вашему каталогу уже не раз гуляли разные кракеры, просто они вам в этом не признавались. :D Ну, стянул сопливый кракер вашу базу данных, и дальше чего с ней делать? Чтобы войти в форум, нужен пароль администратора. А для этого надо подобрать его по хэшу, что требует уже определенных познаний. И даже если он войдет в форум как админ - интереса в этом немного. Форум - не интернет-магазин с номерами кредиток. Такие взломы обычно остаются вообще незамеченными.

 

*** Если совместный хостинг такой небезопасный, зачем он вообще нужен?

 

Видите ли, 95-98% всех сайтов - это статические страницы. Максимум - к ним добавляется счетчик посещений, почтовая форма обратной связи и гостевая книга. Такой сайт клиенты разово заказывают у веб-дизайнеров или сами делают по шаблону, после чего ничего в них серьезно не меняют годами. Так вот, если даже злоумышленник заберется в каталог такого сайта через локальную файловую систему - он не увидит там ничего нового, кроме того, что и так можно увидеть через веб-браузер. А записать туда свои скрипты он не сможет, потому что каталоги для веб-сервера доступны только для чтения, но не для записи. Так что этим клиентам фиолетово, ходит по ним кракер или нет.

 

Если же вы создаете динамический сайт с использованием базы данных, то у вас в веб-каталоге неизбежно появляются некие конфиденциальные данные, тот же логин/пароль для базы данных, конфиденциальные данные покупателей интернет-магазина, участников форума и т.п. Это может представлять для злоумышленника потенциальный интерес и вам следует позаботиться о более адекватном хостинге.

 

*** Так какой же хостинг мне нужен??

 

Вариант 1. Сейчас многие провайдеры предлагают тарифный план с отдельной Апачей и на отдельном адресе IP. Например, caravan.ru - всего около 400 рублей в месяц. В этом случае веб-сервер запускается под вашей учетной записью или учетной записью специального пользователя, типа apache_petrovи взлом его по локальной файловой системе становится невозможен. Только не забудьте убрать права на чтение для "всех", т.е. права на каталоги должны быть 750, а не 755. Дополнительный бонус - можете организовать к форуму полноценный доступ по https.

 

Вариант 2. VPS - Virtual Private Server. Фактически в рамках провайдерской машины вы получаете собственный сервер с правами root, который можете настраивать по своему разумению, заводить пользователей Unix, устанавливать свое программное обеспечение и т.п. Цены - от 500-700 рублей в месяц.

 

Вариант 3. Арендованный сервер. На зарубежных площадках - от 50-70 долларов в месяц, на российских - где-то от 150-200.

 

*** Я не верю ничему, что вы тут написали! Жил я прекрасно под совместным хостингом и ничего не происходило!

Я тоже ничему этому не верю. Я это знаю. :)

Ссылка на комментарий
Поделиться на других сайтах

  • 0

Алексей, спасибо. Думаю многие почерпнут полезное из поста. Как же хорошо, что я "перерос" shared :D

 

Если кто-то придумает название для темы, перенесу в FAQ или Tricks ;)

Ссылка на комментарий
Поделиться на других сайтах

  • 0

Тольков ФАК!

Предлагаю назвать так:

safe mode: off или on?

или

Разновидности хостинга и их уровень (степени) защиты

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Тольков ФАК!

Предлагаю назвать так:

safe mode: off или on?

или

Разновидности хостинга и их уровень (степени) защиты

А если так: "Почему для IPB не подходит shared хостинг?"

Ссылка на комментарий
Поделиться на других сайтах

  • 0
"Чем плох shared хостинг"?
Ссылка на комментарий
Поделиться на других сайтах

  • 0

А по мне, так бред. Т.е. все сказано правильно, но свалено в полную кашу совершенно непонятно кому адресованную и несет таким стилем... м.. знаете, "а в интернете есть сайты, а там страшные веши! Даже людей голых показывают, а еще любой хакер может узнать какого цвета у вас трусы". Ощущение, что навалено все, что человек слышал без осознания - к месту ли это сказано вообще. Особо рассуждения про mod_perl порадовали =) Очень поможет тут всем =)

 

Хотя проблему понять можно, человек сам ее обрисовал. Да, ламеров много, кто думает "ща хостинг сбацаю", только большинство из них дальше слов не уходят, вторая часть быстро сливается, третья в итоге пользуется готовыми панелями в которых, к счастью, за них подумали. Но если сидеть на сисадминских форумах, особо куда они стекаются - то и правда покажется, что шаред это такая жуть, а VPS - единственный выход. Особо если самому в этой каше не вариться - а по некоторым заявлениям видно это так и есть.

 

А "успокоительных" тут есть. Первая - есть отличные решения в виде готовых панелей. Для новичков. Где нормально все настроено включая safe mode. Второе - есть живучие решения без safe mod. Это и mod_fastcgi, это php-fpm (особо если его доделают), это патчи на апач, которые переключают uid чайлда....

 

В общем, выбирайте или хостинг где php от вашего же юзера бегает (а уж сколько проблем с правами, масками, записью тут избежите...) или просто хостера с именем и стажем - кто будет следить за php дырками, которые вдруг поломать могут safe mode (и которые частенько сами доводят его до ума смоими патчами)

Изменено пользователем MiksIr
Ссылка на комментарий
Поделиться на других сайтах

  • 0

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

Из всего этого можно только вынести, что IPB требует выделенного хостинга спешиал для него - это уже давно всем известно, только не из-за безопасности, а из-за его громоздкости.

Для общего блага в продвижении php тут нет ничего нового. По словам алексея perl - вообще тогда одна сплошная дыра.

в общем без комментариев... бред...

Изменено пользователем G*g
Ссылка на комментарий
Поделиться на других сайтах

  • 0
G*g, проблема не в языке, а в правах доступа, насчёт этого всё верно написано.
Ссылка на комментарий
Поделиться на других сайтах

  • 0

Уважаемый G*g, "дыра" в общем понимании - это когда программа неожиданно ведет себя не так, как было запланировано. А в данном случае скриптовые языки ведут себя именно так, как им положено, просто не все знают, как это должно быть. :D Давайте я для ясности переведу на русский два текста:

 

The PHP safe mode is an attempt to solve the shared-server security problem. It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't very realistic, many people, especially ISP's, use safe mode for now.

 

"Безопасный режим" PHP - это попытка решить проблему безопасности на совместном виртуальном хостинге. С точки зрения архитектуры решать эту проблему на уровне PHP неправильно, однако, поскольку альтернативы на уровне веб-сервера и операционной системы не очень реальны, многие люди, особенно хостинг-провайдеры, пока используют "безопасный режим".

Мануал PHP, 42-я глава

 

 

As safe_mode is a name that gives the wrong signals as making PHP safe, we all agreed that we should remove this function. It can never be made totally safe as there will always be ways to circumvent safe_mode through libraries. This kind of functionality also better belongs in the web server or other security scheme.

 

Поскольку слова "безопасный режим" могут вызвать неправильное представление, будто он делает PHP безопасным, мы все решили, что нам следует удалить эту функцию. Он никогда не может быть полностью безопасным, так как всегда остаются способы обойти safe_mode через библиотеки. Этот вид функциональности лучше реализовывать на уровне веб-сервера или по другой схеме безопасности.

Совещание разработчиков PHP в 2005 году,

http://www.php.net/~derick/meeting-notes.html#safe-mode

 

Как видите, разработчики PHP после многолетних попыток ограничить скрипты в лазании по серверу плюнули и сдались. В отличие от отдельных товарищей, которые все еще верят, что "хостер с именем и стажем" или "готовая панель для новичков" могут перебороть архитектуру Юникса и его файловую систему. ;) Впрочем, это действительно - скорее из области психологии и "успокоительных для чайников".

 

Если коротко, на основании своего опыта и здравого смысла резюме я бы предложил такое:

 

Совместный виртуальный (shared) хостинг предполагает, что в каталогах public_html находятся файлы, которые не содержат конфиденциальной информации - например, статические файлы html. В этом виде он удовлетворяет потребности 95-98% клиентов.

 

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

Ссылка на комментарий
Поделиться на других сайтах

  • 0

О правах там как и везде - вроде понимает что пишет с одной стороны... а вроде и нет. Средств организации прав есть несколько и приведенная им далеко не самая оптимальная и описана с ошибками. И ACL на юниксе уже не что-то "новенькое", а давно в ядре и работает (и не только для NTFS).

 

А основную идею можно передать кратко - не ходите к неизвестным хостерам. Я бы выдвинул еще свой лозунг - ходите только к тем, у кого php работает под вашим юзером, но это скорее попытка двигать прогресс =)

 

 

Самое главное - не верить всем подряд, включая и тех, что утверждает "я знаю" =)

Как правило, между тем, кто говорит "я знаю" и тем, кто действительно знает, ибо делал все это - огромная разница =)

Ссылка на комментарий
Поделиться на других сайтах

  • 0
Кстати, очень советую всем серьезным пользователям перечитать то, что пишет в этой ветке MiksIr. В некотором роде его тексты - блестящие образцы... Я бы так не смог. ;) В общем, вы поняли, что я имею в виду. :D
Ссылка на комментарий
Поделиться на других сайтах

  • 0

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

по вашей версии ucoz и многие другие бесплатные php-хостинги уже давно бы лежали. но они не лежат. почему?

почему сайты компании, в которой я работал, хостясь на таком же "левом" хостинге, до сих пор работают?

я видел как ломали и выделенные сервера, но это лишь говорит о криворукости админов, но никак не о "дырявости".

то, что в 6 отменяют safe mode - только огромный плюс, так как толку в нем мало, но есть и другие средства защиты от вашего "лазания" по чужим директориям.

если вы не умеете управлять автомобилем, то вам лучше не садиться за него, так как может настать случай, что вы попадете в аварию. также и здесь. не надо впадать в паранойю.

 

p.s. MiksIr по крайне мере четко формулируют свою мысль и к его словам не придерешься.

Ссылка на комментарий
Поделиться на других сайтах

Гость
Эта тема закрыта для публикации сообщений.

×
×
  • Создать...

Важная информация

Находясь на нашем сайте, вы соглашаетесь на использование файлов cookie, а также с нашим положением о конфиденциальности Политика конфиденциальности и пользовательским соглашением Условия использования.