Каковы рекомендуемые права доступа к каталогу?

145

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

В частности default/files/(и подкаталоги?) settings.php, .htaccessИ что - нибудь еще , что я должен быть в курсе.

извед
источник
1
Здесь также есть ответ: drupal.stackexchange.com/questions/52695/…
Free Radical
Есть блог, который объясняет это красиво и освещает каждый аспект в абстрактной форме. technologymythbuster.blogspot.com/2018/06/…
Калпеш Попат

Ответы:

69

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

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

Пол Джонс
источник
13
Это не относится к каталогу sites / default / files, который должен быть доступен для записи на веб-сервере, иначе у вас будет масса неприятностей.
Роби
3
@rooby Второе предложение разъясняет это.
Кенорб
14
Хотя и написано «Если ваш сайт включает в себя загрузку файлов», но это не единственная причина, по которой вам может потребоваться доступ для записи в каталог файлов. Очень распространенный пример - агрегация js / css, когда пользователи не загружают файлы. Другие модули также могут ожидать, что этот каталог будет доступен для записи.
Роби
91

Та страница друпала, как и многие, очень длинная и запутанная. Но он содержит этот пост Джейсона, который ударил гвоздь по голове:

Отправленный Джейсоном Сэйлом 1 ноября 2010 в 12:40

Спасибо, что написали это и все, но все, что я и 99% людей, читающих эту страницу, действительно хотят, - это список цифр рядом со списком папок.

  • /default на 755
  • /default/files включая все подпапки и файлы на 744 (или 755)
  • /default/themes включая все подпапки и файлы на 755
  • /default/modules включая все подпапки и файлы на 755
  • /default/settings.phpи /default/default.settings.phpна 444
ErichBSchulz
источник
7
Тема длинная и запутанная. Страница соответствует реальности ситуации.
greggles
17
... из Drupal документов! И именно поэтому это должно быть немедленно изменено на что-то простое и понятное! Особенно, когда речь идет о безопасности. ПРОСТО, ПОТОМУ ЧТО это о безопасности! Потому что это принадлежит всем нам. Зараженный сервер - это проблема не только неопытного пользователя Drupal. Это проблема всех нас тогда. Так что не очень полезно держать сложные и плохо написанные документы, вдохновленные разработчиками, чтобы показать сложность и запутанность, а также то, насколько хорошо они справляются с этим. Я не вижу смысла пропускать простое графическое изображение дерева разрешений. Вебчик согласен с этим.
nilsun
3
Почему 755 на / default / files? Разве это не должно быть всегда 744 на тот случай, если кому-то удастся загрузить что-то вредоносное, взломав интерфейс (или из-за плохой конфигурации)? Есть ли причина иметь 755? Как насчет / TMP?
Webdrips
1
Файл settings.php должен быть 440. «Другие» не должны видеть settings.php. 740, если вы хотите иметь возможность писать в него без команд sudo.
Брайден
просто любопытно, почему файл .htaccess в файлах и папке tmp должен быть записан веб-сервером? Разве это не безопасно пометить это 444 так же, как settings.php. Причина, по которой я спрашиваю, заключается в том, что если хакер может загрузить файл junkfile.php в папку файлов через веб-сервер, то файл .htaccess можно заменить. я прав?
kiranking
82

Моя практика создания нового сайта Drupal на сервере заключается в том, чтобы иметь пользователя, который входит в группу веб-серверов (обычно Apache), и чтобы этот пользователь владел всеми файлами Drupal. В Ubuntu это команды для настройки:

# Create a new example user, setting up /var/www/example as their home dir.
useradd -s /bin/bash -d /var/www/example -m example

# Now add that user to the Apache group. On Ubuntu/Debian this group is usually
# called www-data, on CentOS it's usually apache.
usermod -a -G www-data example

# Set up a password for this user.
passwd example

Как только я это настрою, я войду в систему под этим пользователем и установлю Drupal по адресу / var / www / example / docroot или аналогичный, а затем создам каталог файлов вручную и скопирую файл settings.php. Поскольку мы вошли в систему в качестве нашего примера пользователя перед копированием в Drupal, наши права доступа к файлам и их права должны автоматически настраиваться для всех основных файлов и сценариев Drupal (включая файлы .htaccess).

su - example
cd docroot
cp sites/default/default.settings.php sites/default/settings.php

# Temporarily give the web server write permissions to settings.php
chgrp www-data sites/default/settings.php
chmod g+w sites/default/settings.php

Теперь давайте настроим каталог файлов.

# Create the directory.
mkdir sites/default/files

# Now set the group to the Apache group. -R means recursive, and -v means 
# verbose mode.
chgrp -Rv www-data sites/default/files

Далее мы настроим разрешения, чтобы веб-сервер всегда мог записывать в любой файл, который находится в этом каталоге. Мы делаем это с помощью 2775 в нашей команде chmod. 2 означает, что идентификатор группы будет сохранен для любых новых файлов, созданных в этом каталоге. Это означает, что www-данные всегда будут группой для любых файлов, тем самым гарантируя, что веб-сервер и пользователь всегда будут иметь права на запись для любых новых файлов, размещенных в этом каталоге. Первые 7 означают, что владелец (пример) может R (Чтение) W (Запись) и X (Выполнить) любые файлы здесь. Вторая цифра 7 означает, что группа (www-данные) также может отправлять и записывать любые файлы в этом каталоге. Наконец, 5 означает, что другие пользователи могут R и X файлы, но не могут писать.

 chmod 2775 sites/default/files

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

 chmod g+w -R sites/default/files

Теперь Drupal готов к установке. Когда закончите, ОЧЕНЬ важно вернуться в settings.php и убедиться, что у всех пользователей есть только права на чтение.

 chmod 444 sites/default/settings.php

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

q0rban
источник
не безопасно ли установить .htacess на 444 jsut как settings.php? в любом случае, этот файл редко обновляется в ядре drupal.
kiranking
Вы можете установить .htaccess на 444, но это добавит дополнительную головную боль при обновлении ядра Drupal и не сделает ваш сайт более безопасным.
q0rban
30

Папка с файлами Drupal должна быть доступна для записи веб-сервером. Самый безопасный способ сделать это - изменить группу и сделать ее доступной для записи, например так:

chgrp www-data sites/default/files
chmod g+w sites/default/files

За исключением папки для загрузки файлов, наиболее безопасным является chmod 644 для всех файлов, 755 для каталогов.

Это может быть выполнено следующим образом (при запуске в папке Drupal-site указывается .текущий путь):

find . -type f | xargs chmod 644
find . -type d | xargs chmod 755

Помните, что вам нужно chmod g+wбудет выполнить повторную настройку после выполнения вышеуказанной команды, так как она сбросит chmod для всех файлов и папок.

Mikl
источник
2
Этот ответ предполагает: вы находитесь на Ubuntu. Ваш сайт работает только на этом сервере. Это также решает проблему только один раз, вместо того, чтобы сделать это автоматически (например, путем изменения маски).
greggles
Не обязательно Ubuntu, и это по-прежнему полезная мера, даже если на одном сервере работает несколько сайтов. Изменение umask (которое, надо надеяться, уже имеет эти настройки) - это не то, что я бы порекомендовал людям, не разбирающимся в Linux. Я знаю, что это не идеальная безопасность, но давайте не будем допускать, чтобы идеал был здесь врагом добра.
Микл
На мультисайте я бегу chgrp -R www-data sites/*/filesи chmod -R g+w sites/*/filesизбавляюсь от ошибок на странице статуса.
leymannx
20

Любой совет "chmod blah" или "chown X" не имеет смысла, не зная: что за файлы user: group по умолчанию находятся в файлах и от какого пользователя и группы работает ваш веб-сервер.

Drupal Docs, на которые другие ссылаются, довольно хороши в этой теме, но еще один ресурс - это модуль Security Review, который помогает убедиться, что все настроено правильно.

greggles
источник
9

Я отвечу, учитывая, что файлы создаются на сервере с использованием FTP, используя учетные данные, отличные от тех, под которыми работает веб-сервер (обычно Apache работает как nobody / nobody). Это означает, что пользователь, которому принадлежат файлы, созданные вручную перед запуском установщика Drupal (который также включает файлы, загруженные на сервер из архива Drupal), не является пользователем, используемым для запуска веб-сервера (ни имя пользователя, ни группа не совпадают) , Этот сценарий применим также к случаю, когда эти файлы создаются с использованием SSH.

  • Файл settings.php должен быть доступен для записи из установщика Drupal, но после завершения установки предлагается сделать его доступным только для чтения (установщик рекомендует это сделать, и Drupal будет периодически проверять, действительно ли файл доступен только для чтения). В описываемом мной сценарии разрешение этого файла должно быть не менее 644.
  • Файлы .htaccess (которые присутствуют как минимум в двух местах) должны иметь разрешение 644. Пользователь, создавший файл, должен иметь возможность перезаписать файл, если в следующей версии Drupal имеется файл .htaccess, который был обновлен (это произошло уже один раз, когда в этот файл была добавлена ​​строка во избежание проблем с безопасностью). Также возможно установить разрешения на 444, но в этом случае разрешения должны быть изменены обратно на 644, когда файл должен быть обновлен.
  • Каталог, содержащий файлы, созданные модулями ( default/filesкаталог), должен быть (для пользователя, назначенного процессам веб-сервера, который затем является пользователем, назначенным сценариям PHP, работающим на этом веб-сервере):
    • удобочитаемый
    • записываемый
    • проходимый (модули должны быть в состоянии достичь default/files/<directory-used-by-the-module>/<sub-directory-used-by-the-module>)
киамалуно
источник
после прочтения ветки на drupal.org/node/244924 и, в частности, drupal.org/node/244924#comment-8186447, ни один из различных методов не предоставил, как добиться загрузки файлов, чтобы иметь только 660 RW-RW ---- т.е. без исполнения бит. Разве это не главная проблема безопасности?
Киранкинг
8

Рекомендуемые права доступа к файлам / каталогам:

  • Корневой корень Drupal должен быть доступен для чтения всем пользователям (см .: updater.inc ): 0755
  • для публичных каталогов загрузки: 0755 или 0775
  • для частных каталогов загрузки: 0750 или 0770
  • для публично загруженных файлов: 0644 или 0664
  • для личных загруженных файлов: 0640 или 0660
  • для .htaccess в каталогах загрузки (см .: file_create_htaccess () ): 0444 (по умолчанию) или 0644
  • для settings.php только для чтения для всех (и других конфиденциальных файлов): 0440
  • для всех остальных веб-каталогов: 0755
  • для всех остальных веб-файлов: 0644

Рекомендуемое владение файлом / каталогом:

  • владелец всех загружаемых каталогов / файлов должен быть установлен как пользователь Apache,
  • владелец всех веб / исходных каталогов / файлов должен быть установлен как пользователь не Apache,
  • (необязательно) группа всех источников должна быть установлена ​​в группу Apache,

Вот переменные, которые управляют разрешениями dir / file по умолчанию для новых элементов:

file_chmod_directory: 0775
file_chmod_file: 0664

Вот некоторый скрипт для исправления прав доступа: fix-permissions.sh


Читать далее:


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

#!/bin/sh -e
# Script to correct public/private directory and files permissions.
[ -z "$1" ] && { echo Usage: $0 @remote.dst; exit 1; }

DST="$1" && shift
GET_HTTP_GROUP='ps axo user,group,comm | egrep "(apache|httpd)" | grep -v ^root | uniq | cut -d\  -f 1'

drush $* $DST ssh 'PUB=$(drush dd %files) && PRIV=$(drush dd %private) && AGROUP=$('"$GET_HTTP_GROUP"') && chgrp -vR $AGROUP $PUB $PRIV && chmod -vR u+rwX,g+rwX,o+rX $PUB $PRIV'

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

kenorb
источник
очень хороший шпаргалка, в закладки. Хорошая работа ..
kiranking
4

Этот сценарий оболочки находится внизу этой страницы: https://www.drupal.org/node/244924

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

#!/bin/bash
# Help menu
print_help() {
cat <<-HELP
This script is used to fix permissions of a Drupal installation
you need to provide the following arguments:
1) Path to your Drupal installation.
2) Username of the user that you want to give files/directories ownership.
3) HTTPD group name (defaults to www-data for Apache).
Usage: (sudo) bash ${0##*/} --drupal_path=PATH --drupal_user=USER --httpd_group=GROUP
Example: (sudo) bash ${0##*/} --drupal_path=/usr/local/apache2/htdocs --drupal_user=john --httpd_group=www-data
HELP
exit 0
}
if [ $(id -u) != 0 ]; then
  printf "**************************************\n"
  printf "* Error: You must run this with sudo. *\n"
  printf "**************************************\n"
  print_help
  exit 1
fi
drupal_path=${1%/}
drupal_user=${2}
httpd_group="${3:-www-data}"
# Parse Command Line Arguments
while [ $# -gt 0 ]; do
  case "$1" in
    --drupal_path=*)
      drupal_path="${1#*=}"
      ;;
    --drupal_user=*)
      drupal_user="${1#*=}"
      ;;
    --httpd_group=*)
      httpd_group="${1#*=}"
      ;;
    --help) print_help;;
    *)
      printf "***********************************************************\n"
      printf "* Error: Invalid argument, run --help for valid arguments. *\n"
      printf "***********************************************************\n"
      exit 1
  esac
  shift
done
if [ -z "${drupal_path}" ] || [ ! -d "${drupal_path}/sites" ] || [ ! -f "${drupal_path}/core/modules/system/system.module" ] && [ ! -f "${drupal_path}/modules/system/system.module" ]; then
  printf "*********************************************\n"
  printf "* Error: Please provide a valid Drupal path. *\n"
  printf "*********************************************\n"
  print_help
  exit 1
fi
if [ -z "${drupal_user}" ] || [[ $(id -un "${drupal_user}" 2> /dev/null) != "${drupal_user}" ]]; then
  printf "*************************************\n"
  printf "* Error: Please provide a valid user. *\n"
  printf "*************************************\n"
  print_help
  exit 1
fi
cd $drupal_path
printf "Changing ownership of all contents of "${drupal_path}":\n user => "${drupal_user}" \t group => "${httpd_group}"\n"
chown -R ${drupal_user}:${httpd_group} .
printf "Changing permissions of all directories inside "${drupal_path}" to "rwxr-x---"...\n"
find . -type d -exec chmod u=rwx,g=rx,o= '{}' \;
printf "Changing permissions of all files inside "${drupal_path}" to "rw-r-----"...\n"
find . -type f -exec chmod u=rw,g=r,o= '{}' \;
printf "Changing permissions of "files" directories in "${drupal_path}/sites" to "rwxrwx---"...\n"
cd sites
find . -type d -name files -exec chmod ug=rwx,o= '{}' \;
printf "Changing permissions of all files inside all "files" directories in "${drupal_path}/sites" to "rw-rw----"...\n"
printf "Changing permissions of all directories inside all "files" directories in "${drupal_path}/sites" to "rwxrwx---"...\n"
for x in ./*/files; do
    find ${x} -type d -exec chmod ug=rwx,o= '{}' \;
    find ${x} -type f -exec chmod ug=rw,o= '{}' \;
done
echo "Done setting proper permissions on files and directories"
Copy the code above to a file, name it "fix-permissions.sh" and run it as follows:
sudo bash fix-permissions.sh --drupal_path=your/drupal/path --drupal_user=your_user_name

Note: The server group name is assumed "www-data", if it differs use the --httpd_group=GROUP argument.
Ричард Робинсон
источник
2

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

G.Martin
источник
1

Это помогло мне решить проблемы с разрешением OSX. Я нашел его в https://www.drupal.org/node/244924#comment-3741738 пользователем протоплазмы. Я был как у него проблемы после миграции.

[root@localhost]cd /path_to_drupal_installation/sites
[root@localhost]find . -type d -name files -exec chmod ug=rwx,o= '{}' \;
[root@localhost]find . -name files -type d -exec find '{}' -type f \; | while read FILE; do chmod ug=rw,o= "$FILE"; done
[root@localhost]find . -name files -type d -exec find '{}' -type d \; | while read DIR; do chmod ug=rwx,o= "$DIR"; done
cayerdis
источник
-3

Существует модуль под названием « Проверка безопасности», который проверяет, является ли ваш сайт безопасным или нет. Я также нашел очень хорошую ссылку для установки прав доступа к сайту.

Manikandan
источник