Прочитайте плз всю ветку прежде чем баянить.. Вопрос не про слив.
Спасибо за ссылку, изучим, не претендую на всезнайку )
Как раз из за этого у меня и возмущения. MPM-ITK дает слишком много прав php скриптам. Я бы сказал даже что при ITK вообще не важно какие права стоят, они по умолчанию "максимальные"(что 600 что 666 что 777, т.к. скрипт может делать что хочет, хоть себя переписать).
Так и есть, разбито по "группам".
Если скрипт физически не может никуда записать, ни в одну директорию. А если куда то и может(upload дира), то там лежит .htaccess запрещающий запуск скриптов - и как ему шел зальют? А вот с ITK запросто, в любую диру )
А если не у нас в движке, а в вордпресс, дле и тому подобных? Нет возможности сидеть и следить за каждым, проще не давать всем скриптам доступ на запись. Кроме того проблем у меня никогда небыло с паблик движками, т.к. права были распределены нормально, без лишних возможностей. А сейчас когда появился ITK сразу зашелили.. Можете хоть сколько говорить что так удобнее и безопаснее, но для меня факт на лицо ) Да и задачи у всех разные..
Кому не лень, расскажите плз какие права при ITK по вашему мнению должны быть на файлы/директории скажем для типичного сайта на wordpress?
Все это видел, всегда удивляло зачем открывать такую "дыру", обязательно кто нибудь воспользуется, особенно если движок не свой, а один из известных. Тогда понятно почему столько жалоб на заражения сайтов. Имхо давать php скрипту карт бланш очень опрометчивое решение.. Я привык к тому что изначально все запрещено, разрешаешь запись только туда куда это действительно нужно. Насчет авто-обновлений норм движки поддерживают ftp(в автоматическом режиме обновляют по ftp) и им не требуются такие "широкие полномочия".
Ну конечно, на 20 сайтов создадим 20 пользователей, мега круто и удобно )
Как раз таки очень даже не напрасны и мешают выполнить chmod, вы попробуйте. Если запуск не от владельца чтобы исполнить chmod нужно чтобы были права 666. Ваше мнение ошибочно в данном случае. Даже если заливают шелл, кроме как посмотреть больше ничего не могут сделать. А те каталоги в которые можно заливать из вне(файлы, картинки и т.п.) можно и нужно закрывать от исполнения php скриптов в нем, если в этом нет особой потребности.
Действенное решение не пускать php скрипты "в разгул" с наивысшими правами. Обновление ПО не спасет, каждый день не станешь следить, тем более если сайтов 10-20-30, в итоге это приведет к тому что по факту заражения уже станешь обновлять..
Наверняка в такой политики есть своя логика, открывая одну дыру закрывают другу. Но блин имхо без itk было более секьюрно )
Проблема в том что по умолчанию при правах 600 php скрипт имеет доступ ко всему нутру сайта(может изменять/создавать любые файлы) - разве это нормально? Мне так через dle залили шел и в рамках одного юзера покоцали и другие сайты которые под этим юзером.
Пофиксилось так:
Вместо "AssignUserID site_web_user site_web_user" - прописал как советовал umercomp "AssignUserID apache site_web_user" и немного изменил права /var/www/site_web_user.
Печально что это приходится делать в ручную, т.к. ISP Manager по умолчанию ставит другие права при добавлении конфига в vhost и получается такой косяк(или фича?)..
Да все равно примерно такие права и стояли, разве что группа другая. На всякий случай попробовал как вы написали не помогло. Из php скрипта спокойно редактируется любой объект :(
501 site_web_user mgrsecure
Работает от apache, пробовал. Не помогло. Закоментить строку "AssignUserID..." тоже пробовал, результат тот же :(
AssignUserID www-data site_web_user
Нет такого пользователя "www-data"..
Чтобы при обращении по IP выдавалась заглушка, а не сайт? Вписать руками заглушку в httpd.conf virtual host в самом верху. Или добавить домен любой(test.com) и перенести его в самый верх в конфиге, выше остальных хостов, тогда он будет открываться по дефолту.
negrem, в beta.webmaster.yandex.ru добавлен сайт? Если нет добавьте и посмотре, про минусинск они указывают там.