Хостинг 201 на nic.ru. Есть некий идентификатор хостинга: mysite.
Есть пользователь ssh, имя которого совпадает с идентификатором хостинга: mysite.
Сайт сделан на drupal 7.15, использую WinSCP.
Через панель управления хостингом включены нужные модули php 5.3, сайт работает в автоматическом режиме, полет нормальный.
Задался вопросом: а все ли нормально с безопасностью?
Поставил модуль security_review, а он в ответ "Some files and directories in your install are writable by the server".
Знаний и опыта работы с apache = 0. Да и в целом что касается unix, хостинга, безопасности - на том же уровне.
Сразу за поиск. Тут вроде все написано: http://www.drupal.org/node/244924.
For example, on many systems the Apache process runs as a user called "www-data" that is in a group called "www-data". This user should be able to read all of the files in your Drupal directory either by group permissions or by "other" permissions. It should not have write permissions to the code in your Drupal directory. If you use features of Drupal which require the "files" directory, then give the www-data user the permission to write files only in that directory.
Суть проблемы: похоже что сайт работает под пользователем mysite, т.к.:
1. В httpd.conf (он же httpd.conf.auto) написано
Group mysite
User mysite
2. WinSCP показывает (properties на файле) что
права: 0640
group = mysite [some_uid]
owner = mysite [some_uid]
Получается что у пользователя под которым работает веб-сервер - есть полные права на папку друпала, т.к. он и есть ее владелец.
На nic.ru нашел следующую инфу (http://hosting.nic.ru/faq/site.shtml#q4):
Для чего нужен ручной режим настройки виртуального сервера и/или сайта?
Панель управления предоставляет для автоматического конфигурирования ограниченный набор параметров сайтов и виртуального сервера, но достаточный для работы подавляющего большинства сайтов. На случай нехватки предоставляемого функционала или необходимости «тонкой» настройки и предусмотрена возможность перехода на ручной режим настройки виртуального сервера и сайтов.
При переключении в ручной режим веб-серверов становятся доступны для редактирования файлы конфигурации:
/home/идентификатор/etc/httpd.conf.manual — основной конфигурационный файл веб-сервера Apache;
/home/идентификатор/etc/nginx/nginx.conf.manual — основной конфигурационный файл веб-сервера Nginx.
При переключении в ручной режим сайта:
/home/идентификатор/ваш_домен/conf/virtual.conf.manual — конфигурационный файл виртуального хоста Apache;
/home/идентификатор/etc/nginx/ваш_домен.vhost.conf.manual — конфигурационный файл виртуального хоста Nginx.
Суть вопроса: получается что при размещении drupal-сайта на nic.ru я должен перевести веб-сервер и/или сайт в ручной режим и произвести определенные настройки, чтобы сайт работал под другим пользователем?
А под каким пользоваталем/группой? Надо писать в nic.ru и спрашивать какие там есть пользователи и группы?
Почему об этом ни слова ни в одной инструкции по установке drupal на nic.ru. И поиск ни к чему не привел.
Или я все же что-то упустил и все должно как-то правильно работать без лишних действий?
Комментарии
Много букаф.
Не нужно ни в какой ручной режим переводить сервер. Знаете такую поговорку "работает - не трогай!"? Вот это как раз такой случай.
То, что пишет модуль секюрити ревьюв - он это будет писать на 99% сайтов. И паниковать из-за этого не стоит (играясь с правами на папки потом себе проблем больше наживете). У вас виртуальный хостинг, и никакую другую группу вам не дадут поставить, слишком много чести для простого хостинга.
Я бы на вашем месте больше озадачился вопросом создания своих бекапов, не стал бы такое доверять хостингу.
В данном случае работает не правильно и это в любой момент может аукнуться.
Какие тут могут быть проблемы? Я разве многого прошу? У веб-сервера должно быть право на запись только в папки, которые указаны здесь "admin/settings/file-system" (папка с сохраняемыми файлами + временная), а на все остальное - только чтение.
Неужели на виртуальном хостинге такое нельзя сделать?
Проблема в грамотной реализации.
Большей частью такое делают только на VDS, так как только рут может сменить группу например.
На шареде слишком , Эмм, напряжна такая реализация и несет много проблем, а значит тикетов. Отделываются простыми решениями.
В самом начале эры хочтинга - процесс из под апача не мог вообще никуда писать, если права были не 777. Что по сути сплошная дыра. Которую потом еще open base dir опцией закрывали.
Следующим шагом была возможность разграничение прав по вирт хостам или юзерам. Лучше но опять же - возможность запуска кода злоумышленником - дает возможность пере записи файлов.
Мы скоро анонсируем решение этой проблемы, пока что обкатываем. Пришлось кодить модуль для апача.