Права на файлы и папки Drupal 7

Главные вкладки

Аватар пользователя Hades Hades 1 марта 2015 в 23:55

Очень не плохой скрипт был дан в комментарии... https://www.drupal.org/node/244924#comment-6600078
Изменил и доработал его под себя:

#!/bin/bash
# Script made by Alex Belyj, admin@azfest.ru
read -n 1 -p "Ну я начну разруливать права а Вы пока чайку попейте, хорошо? (y/[a]): " AMSURE
[ "$AMSURE" = "y" ] || exit
echo "" 1>&2
echo "Начинаю изменение прав..."
echo "Устанавливаю владельца www-data для всех папок и файлов"
chown -R www-data:www-data './'
echo "Выставляю права 755 для всех папок"
find './' -type d -exec chmod 755 {} \;
echo "Выставляю права 644 для всех файлов"
find './' -type f -exec chmod 644 {} \;
echo "Выставляю права 440 для .htaccess"
chmod 440 './.htaccess'
echo "Выставляю права 775 для sites"
chmod 775 './sites'
echo "Выставляю права 775 для sites/default"
chmod 755 './sites/default'
echo "Выставляю права 775 для sites/default/files"
chmod 775 './sites/default/files'
echo "Корректирую права g+w для поддеррикторий sites/default/files"
chmod g+w -R './sites/default/files'
echo "Выставляю права 440 для sites/default/files/.htaccess"
chmod 440 './sites/default/files/.htaccess'
echo "Выставляю права 440 для sites/default/settings.php"
chmod 440 './sites/default/settings.php'
echo "Выставляю права 440 для sites/default/default.settings.php"
chmod 440 './sites/default/default.settings.php'
echo "Выставляю права 775 для sites/all/themes"
chmod 755 -R './sites/all/themes'
echo "Выставляю права 775 для sites/all/modules"
chmod 755 -R './sites/all/modules'
echo "Выставляю права 775 для sites/all/libraries"
chmod 755 -R './sites/all/libraries'
echo "Изменение прав закончил! Убедись, что всё верно..."

1. Скопируйте код скрипта и сохраните под названием "permissions.sh" в папке для локальных скриптов Bash. Соблюдайте кодировку UTF-8 (для нормального отображения кириллических символов в комментариях echo командной строки) и UNIX формат окончания строк (иначе получите /R в конце каждой строки):

nano /usr/local/bin/permissions.sh

2. Сделайте скрипт исполняемым:

chmod a+x /usr/local/bin/permissions.sh

3. Перейдите в корень вашего сайта:

cd /ваш_сайт

4. Выполните скрипт и согласитесь с началом выполнения:

permissions.sh
y

PS: Если у вас "чистый" Drupal, то некоторые папки, например libraries или files, ещё могут быть не созданы. Так же если вы используете папку tmp вашей ОС, то в вашем Drupal её не будет. В этом случае выведется ошибка, что файла или папки не существует - это нормально. Рекомендую пользоваться скриптом на финальных этапах разработки или при переносе на хостинг, когда вся структура файлов и папок уже создана.
PSS: Работа скрипта многократно проверена на Drupal 7 сайтах в ОС Debian 7 Wheezy.

UPD 2015.03.04: В скрипт вначале добавлена проверка на выполнение, при случайном запуске будет возможность отмены. Изменен алгоритм запуска скрипта. К сообщению прикреплён файл "permissions.zip" с вложенным скриптом.

ВложениеРазмер
Иконка пакета permissions.zip756 байт

Комментарии

Аватар пользователя bsyomov bsyomov 2 марта 2015 в 12:19

Первое и основное - куда лучше будет, если владельцем файлов будет другой пользователь. И права на запись всюду, кроме sites/*/files и каталога для временных фалов, будут только у него.
Также, tmp разумнее внести выше корня сайта.

Шаг 2 лишний - выполнять скрипт можно не копируя его куда-либо, а если создавать его в /usr/local/bin, то и путь писать до него не придётся.
Если в первой строке написать #!/bin/bash и сделать файл исполнимым, вызывать можно просто как permissions.sh

Аватар пользователя Hades Hades 4 марта 2015 в 0:36

"bsyomov" wrote:
Первое и основное - куда лучше будет, если владельцем файлов будет другой пользователь. И права на запись всюду, кроме sites/*/files и каталога для временных фалов, будут только у него.
Также, tmp разумнее внести выше корня сайта.
Шаг 2 лишний - выполнять скрипт можно не копируя его куда-либо, а если создавать его в /usr/local/bin, то и путь писать до него не придётся.
Если в первой строке написать #!/bin/bash и сделать файл исполнимым, вызывать можно просто как permissions.sh

Благодарю за советы!
1. С владельцами пока возможности разбираться нет. Весь этот скрипт родился вместе с переездом на новое железо. А т.к. время ограничено пока что пришлось найти быстрый вариант. Пользователю www-data запрещён доступ к консоли:

usermod -s /bin/false www-data

2. С tmp разобрался. Скопировал готовый конфиг вебсервера и забыл переписать параметр php_admin_value open_basedir. Поэтому все сайты по умолчанию у меня были ограничены своей папкой, в том числе и папка с временными файлами. Сейчас разобрался, поправил. Из скрипта шаг с этой папкой удалил за ненадобностью.
3. Это мой первый скрипт. Написан интуитивно без особых знаний структуры и нюансов работы bash. Но по вашей наводке познал много нового и интересного. Алгоритм использования скрипта переписан. Добавлена проверка на исполнение в начало.

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

Аватар пользователя bsyomov bsyomov 4 марта 2015 в 2:33

Смотрите: создаёте пользователя, с шелл и прочим. Он будет владельцем всех файлов. Для примера, у него будет имя user и группа user. Будет заливать файлы, например, по ssh, запускать drush и прочее.
А веб сервер запускаете от пользователя www-data и группы user. Это можно сделать с помощью apache-mpm-itk(для апача), или отдельного пула php-fpm, прописав соответственного пользователя и группу в конфиге виртуального хоста/пула.

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

Также имеет смысл создавать отдельных пользователей для разных сайтов.

Аватар пользователя .poltergeist .poltergeist 4 марта 2015 в 3:38

bsyomov wrote:
Смотрите: создаёте пользователя, с шелл и прочим. Он будет владельцем всех файлов. Для примера, у него будет имя user и группа user. Будет заливать файлы, например, по ssh, запускать drush и прочее.
А веб сервер запускаете от пользователя www-data и группы user. Это можно сделать с помощью apache-mpm-itk(для апача), или отдельного пула php-fpm, прописав соответственного пользователя и группу в конфиге виртуального хоста/пула.

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

Также имеет смысл создавать отдельных пользователей для разных сайтов.


согласен, но обычно утекают пассы куда банальнее)

Аватар пользователя bsyomov bsyomov 4 марта 2015 в 6:51

С утеканием паролей бороться можно другими средствами: например не используя их, а используя ключи и sftp, применять защиту от брутфорса, и.т.п.

А тут речь, собственно о правах и файловой системе. А не о безопасности в целом.

В общем, то что у кого-то где-то утекают пароли, не значит, что не надо правильно подходить к правам fs. Smile

Аватар пользователя .poltergeist .poltergeist 4 марта 2015 в 18:59

да) я имел в виду, что бывает клиент заказывает аудит, далее проводятся все необходимые работы и бац! оказывается один из менеджеров клиента имеет paroli.txt на hdd, подключает его дома, в гостях и черт знает где. надо проводить ликбез. я тут занят сейчас презентацией на эту тему Biggrin так что главная уязвимость это прокладка между монитором и креслом, ничего не меняется))