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

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


Вопрос

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

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

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

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

  • 0

Кажется, пошел уже чистый флуд... Отвечу маленьким примером. Вот сейчас вечер 1-го апреля. Набираю http://www.ucoz.ru/. Вижу текст:

 

На сервере ведутся плановые технические работы

 

Идут технические работы, связанные с обновлением системы. Планируемое окончание всех работ – 31-е марта.

 

Приносим извинения за временные неудобства.

 

:D Это не случайное совпадение, поверьте. Есть у меня информация и с "другой стороны"...

 

А вообще хочу всех успокоить: IPB и всякие там форумы кракерам нафиг не нужны. Как, кстати, и большинство сайтов. Навару с них чуть. Ну, повыпендриваться перед другим таким же малолетним чайником. Ну, написать фигню какую-нибудь на странице.

 

Серьезная охота идет только за паролем root, ценятся также пароли к пользователям, которые могут зайти по ssh. Собственно, специалисты по безопасности закрытием подобных дыр и занимаются. А что происходит на 5-баксовом shared хостинге - им параллельно. Может, кто пароль к БД клиента подсмотрел через файловую систему. А может, на компьютере клиента троян пасется. Мне вот сосед на днях фотографии притащил на флешке и честно предупредил: там, дескать, вирус, подцепил у знакомых на фирме; так этот вирус у них по флешкам уже года три как бегает, они к нему привыкли и даже бороться перестали. Проверил - троян... Кстати, у этой фирмы и сайт свой есть. ;)

 

Также иногда целенаправленно ломают некоторые интернет-магазины. А БД с многолетним флудом пользователей - кому это надо? Поэтому, думаю, админы IPB могут спать спокойно - что на shared hosting, что на любом другом. :)

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

  • 0
Также иногда целенаправленно ломают некоторые интернет-магазины. А БД с многолетним флудом пользователей - кому это надо? Поэтому, думаю, админы IPB могут спать спокойно - что на shared hosting, что на любом другом.
Ну, как сказать... В общем случае - да, не надо... но есть и конкуренция, просто хулиганы. Даже взлом некоммерческого сайта для него может стать катастрофой. Многие вкладываются в свои проекты, сидят днями и ночами, берегут и дорожат. Так что, думаю, почитать это будет полезно всем. alexei1966, спасибо.
Ссылка на комментарий
Поделиться на других сайтах

  • 0

Gg & Mikser ну вы бы уж помолчали, от вас тут только необоснованное нытье и ничего полезного. Надеюсь все это заметили.

2 Алексей спасибо за ценные советы.

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

  • 0
Gg & Mikser ну вы бы уж помолчали, от вас тут только необоснованное нытье и ничего полезного. Надеюсь все это заметили.

2 Алексей спасибо за ценные советы.

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

плюс про open_basedir он явно палку перегнул. ваше дело - читайте.

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

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

плюс про open_basedir он явно палку перегнул. ваше дело - читайте.

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

Да и нигде он не говорил про чью то тупость, прото у кого то больше опыта у кого то меньше и для того существуют такие места как например этот форум чтобы опытом делиться. А если нечем или не хочешь делится, что толку сидеть тут и пыхтеть.

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

  • 0

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

Так же, надеюсь, все заметили утверждения "что в принципе настроить то можно, но никто из хостеров делать это не будет, потому что им это не нужно".

 

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

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

  • 0
У кого сложилось не хорошее впечатление - вас никто не заставляет вообще заходить в эту тему. Как говорится: давай те не будем кормить троллей и перестанем оффтопить. Только где тот кто обещал тему переименовать и в другой раздел поставить?
Ссылка на комментарий
Поделиться на других сайтах

  • 0
У кого сложилось не хорошее впечатление - вас никто не заставляет вообще заходить в эту тему. Как говорится: давай те не будем кормить троллей и перестанем оффтопить. Только где тот кто обещал тему переименовать и в другой раздел поставить?

Спорят, я пока не переносил. Не хамите.

 

P.S. Не стоит беспокоиться, темя прикреплена и о ней не забудут.

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

  • 0

Ок, если по существу, попробую сформулировать свои знания (занимался хостингом от админа до менджера, сейчас уже совсем в другой области, так что ни с кем не аффилирован =))) и дополнить/поправить Алексея и вообще начать с того, как все начиналось =)

 

Изначальный посыл у Алексея правильный. В юниксе права разграничиваются на основе uid - т.е. индентификатора пользователя. Так же в юниксе рождение нового процесса с нуля (exec) - очень долгая и затратная операция. Граздо более веселая операция - "деление" процесса (fork).

 

Изначально, когда веб рождался, был только CGI - или сишные программы или чаще всего - perl. Тут принцип простой - был вебсервер, который работает от юзера, допустим, www. Есть скрипт CGI. Если запрос приходил на скрипт - вебсервер его запускал. Так как скрипты тогда были не так уж часты, все были довольны - вебсервер жил постоянно в памяти и делал fork-и для новых клиентов, а для CGI делался тяжелый exec, но это было не очень часто.

 

Так как www должен был читать файлы у юзера - он по определению имел туда доступ, но вебсервер неподконтролен юзеру, так что если не брать во внимание возможные дыры в веб-сервере, такой доступ безопасен. А вот о CGI такого не скажешь - и придумали suexec. Это прослойка между вебсервером и CGI скриптом которая умеет менять юзера, от которого она запущена (эта возможность заложена в юниксе) - вебсервер делал exec на suexec, тот менял права на указанного юзера и делал exec на CGI скрипт пользователя, который запускался от имени юзера уже и не имел соответственно доступа к другим.

 

Потом появился PHP. Его огромным плюсом, за который его полюбили, была возможность работы как модуль апача (вебсервера), а значит хорошее быстродействие (exec-ов там не делается вообще). ИМХО, это во многом и определил его торжественно развитие и задвигание Perl-a. Для перла были тоже решения как модуль апача, самое известное это mod_perl, но там никто и не думал о безопасности - задачи были другие. А разработчики PHP думали.

 

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

 

Опять ИМХО - этот дурацкий сейф мод в угоду непонятно кому был тормозящий прогресс ошибкой =) Но что случилось, уже не исправить.

 

Итак, имеется mod_php имеющий доступ ко всем файлам системы (совершенно не важно как это реализовано - есть куча способов сделать это от обычных user/group/other до продвинутых ACL и еще более продвинутых RBAC), но программно все возможные варианты досупа к чужим файлам прикрыты.

 

Звучит, конечно, страшно пока не вспомнишь, что и разделение прав у пользователей в юниксе - это тоже в общем программное разделение, заложенное в ядре, а уж сколько локальных эксплойтов (позволяющих получить права любого юзера) было во времена развития линукса... жуть =) Но все же доверия к разработчиком ядра больше, чем к разработчика PHP, соглашусь, так что попытки перевести рельсы на uid не оставлялись.

 

Первое, конечно, это запускать PHP как обычный CGI под управлением suexec. Правда, тут выплыли некторые косяки с авторизацией и был изобретен suphp. Кстати, алексей, suphp - это всего лишь сервисная надстройка над suexec - именно его она и использует, так что выигрыша быстродействия suphp не дает никакого. Какие еще решения?

 

- запуск кучи вебсерверов по одному для каждого юзера - очень накладно, так как огромное число процессов работает вхолостую занимая память. Это единственная проблема, остальные (типа расходв на администрирование, отдельные адреса и т.д.) - это не проблема, это так, сгущение красок.

 

- попытка научить апач менять пользователя - есть кустарное решение в виде модуля которое меняет uid поняв к кому пришел запрос (минус - после отработки запроса процесс умирает и нужно fork-ать новый, тогда как в обычном режиме один процесс может отработать большую очередь запросов) - встречался, изпользут такое. Есть решение от разработчиков в апаче 2, но в общем ничего хорошего о его стабильности не слышал (хотя в свое время кто-то вроде говорил, что и его используют)

 

- самое удачное и перспективное решение, как мне кажется - mod_fastcgi. Тут разделяется вебсервер и PHP, последний работает от своего пользователя, а счастье привносит менеджер запуска этого PHP - он умеет рождать (exec) новые процессы PHP, протокол fastcgi позволяет прогонять через один PHP процесс множество запросов, а менеджер следит - если какой-то процесс PHP долго неактивен - он его убивает, а у другого юзера если приходится должно ждать в очереди - открывает "вторую кассу" =) В общем, работает очень похоже на то, как работает Апач при обслуживании запросов. Т.е. решение, конечно, хуже чистого mod_php по производительности, но значительно лучше CGI режима при той же безопасности. Однако, рещение широкого распространения не получило опять же из-за разработчиков PHP - реализация fastcgi режима ими далека от совершенства и возникают неприятные моменты (с которыми можно бороться, но это уже опыт).

 

- а будущее тут - php-fpm патч. Это замена PHP-ной реализации fastcgi, которое имеет много вкустностей (кстати, рано или поздно этот патч войдет в основную ветку PHP). Будущее - потому что основная вкусность не реализована - это менеджер процессов для множества юзеров почти так, как описано выше, но без косяков так как уже внутри PHP =) Прелесть тут еще одна - fastcgi протокол открытый, и PHP может напрямую получать запросы уже не от апача, а от популярных нынче легких веб-сереров (nginx, lighttpd).

 

Резюмируя. Есть два подхода - програмное разделение прав и перекладывание разделение прав на ядро юникса. Второй подход выглядит более безопасным, но кушает ресурсы более чем первых. Первый подход используется достаточно давно, большинство косяков выловлено, опасность представляет 1) люди не умеющие настраивать безопасность, 2) дыры в самом PHP. Среди профессиональных хостеров первое не встречается, второе фиксится сразу же (и случается не часто)

 

Все остальные настройки - они известны всем и каждому. Прочие отличные от PHP скрипты запускаются как CGI через врапер ключая exec cmd для SSI. Это уже ответственность безопасности разработчиков Apache.

 

Теперь про квалификацию и ответственность. Хостеры есть разные. Есть вася_купивший_сервер, есть его разновидность - вася_считающий_себя_знатоком. Есть начинающие хостеры с головой. Есть профессионалы. Возможно Алексей общался только с первыми (они в общем в большинстве своем и сидят на форумах) - ибо всякие душещипательные истории "Хостеру пофиг", "хостер из вредности отключит safe mod" и т.д. - это вот к ним относится. Выбирая левого хостера - скорее всего получите кучу проблем и без пресловутого safe mode. У второй категории в принципе все лучше, люди там умнее, с пользователями разговаривать уже учаться на их языке... но в общем ясно дело, что "в семье не без урода". Читайте хостниг-форумы, как ведут себя представители хостера, какие о нем отзывы и т.д. Третий вариант - профессионалы, которые в принципе не допустят примитивных ошибок начинающих и которые умеют внятно говорит... но и стоят подороже, конечно.

 

Резюмируя-2: Можно ли получит хак через хостера? - да, можно, чем "левее" хостер, тем выше вероятность (но может и кирпич упасть на голову и уже будет проблема не актуальна). Зависит ли это от того - как запущен PHP - да, но слабо, очень слабо - как правило зависит лишь от дураков, а дураку все равно, что неправильно настраивать - права и группы или PHP.

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

  • 0

Надо же, мои посты уже не считают "бредом". ;)

 

Давайте еще раз повторю свою мысль в другой редакции. Есть два вида организации взаимодействия пользователь - веб-сервер.

 

При первом (веб-сервер запускается под пользователем или специальным отдельным пользователем вида apache_petrov) ваша конфиденциальность по умолчанию защищена архитектурой Юникса. Взломщик может добраться до вашей БД только через "парадный ход", а он обычно защищен.

 

При втором способе (виртуальный совместный хостинг) ваши данные по умолчанию полностью открыты той же самой архитектурой Юникса, к ним имеют доступ еще 100-200 пользователей. Администраторы хостера должны закрыть доступ со стороны "чужих" пользователей для каждого интерфейса отдельно, вручную. При этом любая дыра в любой библиотеке, используемой Апачей (а их несколько десятков!), мгновенно сведет усилия администраторов на нет (именно об этом писали разработчики PHP, когда обосновывали прекращение работы над safe mode). Следует также помнить, что сведения о дырах в библиотеках обычно поступают к разработчикам с большим опозданием, когда кракеры уже успели вовсю этой дырой попользоваться.

 

Далее - каждый выбирает по себе женщину, религию и хостинг. :D Я вот предпочел бы иметь защиту архитектурой Юникса. Кому-то ближе руки народных умельцев от хостинга и сэкономленные 5 долларов в месяц. :)

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

  • 0

Бред был в сторону попытки описания технической стороны - а косяков там было очень много.

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

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

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

  • 0

Остается прояснить анатомические детали: как клиенту определять прямизну рук сисадминов хостера, которых он в глаза не видел и не увидит. Определить прямизну ног сотрудницы, заключающей договор о хостинге как-то легче. :D

 

Верить "имени" провайдера? Загляните в статистику по российским веб-хостерам:

 

http://internet.cnews.ru/hosting/stat/

 

Возьмем для примера Вальюхост, в просторечии - Валуй. Реально крупнейший российский провайдер. А вот в прямизне рук валуйских админов я (и не только я) сильно не уверен. Тем не менее лично знаю одну даму, которая валуйскими услугами крайне довольна. В общем, сколько людей, столько и мнений. ;)

 

Если конкретно про историю, с которой началось обсуждение - с вероятностью 99% кракеры получили доступ к базе потому, что физически находились на том же виртуальном хостинге. Они подсмотрели логин/пароль, который лежит в явном виде, и дальше через какой-нибудь phpMyAdmin слили БД. А что делать дальше - не знали, даже простой пароль не смогли подобрать. Были бы трояны/соц.инженерия - в руки к кракерам попал бы пароль админа. "Дырявые скрипты" - это об чем? Хостинг и еще раз хостинг...

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

  • 0

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

И вероятностями тут глупо оперировать не узнав, хотя бы, хостинг.

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

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

  • 0

Риск есть в любом деле. Вы можете умереть в любую секунду с небольшой вероятностью. Утрата каких-то жалких файлов - это мелочи. В сравнении со многими и многими вещами.

 

Приобретая услуги любого хостинга, вы всегда рискуете потерять информацию. Shared, не shared .. who cares. Там работают люди, которые ошибаются. Везде работают люди, которые ошибаются.

 

Если хотите полностью взять ответственность на себя - поставьте сервер дома и настройте самостоятельно. И все равно - никаких гарантий.

 

По-моему, это очевидные вещи. О чем тема?

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

  • 0

Двумя руками "за" выступление WildRAID! Если вы выставляете свой сайт в Интернет, то должны быть готовы к тому, что однажды до него кто-то доберется с "черного хода". Это как вождение автомобиля - за 10 лет вождения непременно будут и вмятины, и столкновения - не ты, так в тебя... Надо к этому относиться по-философски. Быть психологически готовым к взлому, а при обнаружении следов взлома - спокойно действовать.

 

Я тут просмотрел структуру IPB 2.3.6 - она, увы, не модульная. И она предполагает существование каталогов с возможностью записи внутри этого дерева. Тем не менее некоторую пакость кракерам можно сделать - конечно, если хостер поможет. ;) Сразу говорю - не панацея, но хоть что-то.

 

================

1. Обычно в тарифном плане есть возможность заводить несколько виртуальных хостов. Заводим кроме основного forumtest.domain.ru хост forumtestuploads.domain.ru.

 

2. Передвигаем (mv) туда каталог uploads - это единственный каталог IPB, который должен быть постоянно открыт на запись веб-сервером.

 

3. Заходим в админку - "Утилиты и настройки" - "Общие настройки". Меняем "URL к директории для загрузок" и "Путь к директории 'upload'" на новые - forumtestuploads.domain.ru и что-то вроде /www/petrov/forumtestuploads.domain.ru/html/uploads.

 

4. Теперь все файлы и каталоги, оставшиеся в каталоге IPB, делаем доступными только для чтения. С этим могут быть проблемы, поэтому лучше попросить хостера сделать из корневого каталога вашего виртуального хоста что-то вроде:

find ./ -type d -exec chmod 550 '{}' \;

find ./ -type f -exec chmod 440 '{}' \;

 

5. Далее просим хостера внести в конфигурационный файл Апачи для основного виртуального хоста форума строчку:

 

<VirtualHost 1.1.1.1:80>

SetEnv DBPassword mypass

 

6. В файл conf_global.php меняем строчку:

$INFO['sql_pass'] = $_SERVER["DBPassword"];

 

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

chown petrov ./* -R

 

================

 

Что получаем в итоге.

1. Основные скрипты форума отделены от подгружаемых данных и имеют права только на чтение. Поэтому кракер не сможет их модифицировать. Это имеет и обратную сторону - вы не сможете подгрузить через админку новые языковые файлы, рисунки для оформления и т.п., пока не измените атрибуты у каталогов. С другой стороны - это не каждый день надо. Зато спать будете спокойно. :D

 

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

 

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

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

  • 0
А что помешает человеку, загрузившему что-то свое сделать chmod 777 на файлы форума?

Поконкретнее, пожалуйста. А то много догадок приходится делать насчет вашего "человека, загрузившего что-то свое". :D Что за "человек", какие у него права, что именно и в какой каталог он грузит? И каким образом он потом меняет права у чужих файлов?

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

  • 0

Это вы поподробнее, что своим шаманством с атрибутами на чтение хотите сделать - защита от чего именно это?

find ./ -type d -exec chmod 550 '{}' \;

find ./ -type f -exec chmod 440 '{}' \;

Кстати, chmod -R a-w * - так, пожалуй, пишется правильно

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

  • 0
Извините, мое терпение не беспредельно - на этом уровне диалог с вами считаю бессмысленным. Я свою точку зрения изложил абсолютно ясно и предложил конкретные рекомендации по улучшению безопасности IPB на виртуальном хостинге. Желаю вам также излагать мысли конкретно, а не рассказывать нечто про "человека, загрузившего что-то свое" и "админов с прямыми руками".
Ссылка на комментарий
Поделиться на других сайтах

  • 0
Вы изложили "что нужно сделать", а я спрашиваю - "зачем и как это поможет".

По-моему, я один раз уже объяснил. Но если вы не поняли - объясняю лично вам еще раз другими словами. :D

 

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

 

2. Кракер не может более ничего испортить в каталогах cache/, так как они также закрыты от записи.

 

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

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

  • 0
Злоумышленник, получивший права веб-сервера, более не может просто так "подсмотреть" пароль к базе данных

Что-то я запутался :D А PHP с чьими правами запускается в вашем варианте?

 

2. Кракер не может более ничего испортить в каталогах cache/, так как они также закрыты от записи.

На рабочем сервере их и так можно держать RO, скины править на тестовом и заливать готовые. Это более практично и прозрачно, имхо.

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

  • 0
Злоумышленник, получивший права веб-сервера, более не может просто так "подсмотреть" пароль к базе данных

Что-то я запутался :D А PHP с чьими правами запускается в вашем варианте?

Веб-сервера. Мы рассматриваем виртуальный совместный хостинг (shared).

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

  • 0
Значит злоумышленник с правами веб-сервера не может прочитать конфиг, а PHP с теми же правами может? Похоже стоит ещё больше запутаться...
Ссылка на комментарий
Поделиться на других сайтах

  • 0
Так еще раз - в чем смысл установки r-x на файлы владельца petrov, если запускаемый злоумышлеником скрипт имеет владельца apache. Изменено пользователем MiksIr
Ссылка на комментарий
Поделиться на других сайтах

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

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

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

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