Правильные файловые права для WordPress [закрыто]


399

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

Короче мой вопрос такой. Какие разрешения я должен иметь для следующего:

  1. корневая папка, в которой хранится весь контент WordPress
  2. WP-администратора
  3. WP-содержание
  4. WP-включает в себя

а потом все файлы в каждой из этих папок?


По сути, только папка загрузки Wordpress должна быть 777, но это будет серьезной угрозой безопасности. Если вы используете сервер с включенным Suphp, нет необходимости изменять разрешения вручную.
— Али Ф

4
Я голосую за то, чтобы закрыть этот вопрос как не по теме, потому что это не по теме в отрывке вики-тэга: «К не относящимся к теме вопросам относятся вопросы, касающиеся разработки тем, администрирования WordPress, рекомендаций по управлению, конфигурации сервера и т. Д.»
— Adriaan

Ответы:


499

При настройке WP вам (веб-серверу) может потребоваться доступ на запись к файлам. Таким образом, права доступа могут быть потеряны.

chown www-data:www-data  -R * # Let Apache be owner
find . -type d -exec chmod 755 {} \;  # Change directory permissions rwxr-xr-x
find . -type f -exec chmod 644 {} \;  # Change file permissions rw-r--r--

После настройки вы должны ужесточить права доступа , согласно Hardening WordPress, все файлы, кроме wp-контента, должны быть доступны для записи только вашей учетной записи пользователя. wp-контент должен быть доступен для записи и для www-данных .

chown <username>:<username>  -R * # Let your useraccount be owner
chown www-data:www-data wp-content # Let apache be owner of wp-content

Возможно, вы захотите изменить содержимое в wp-content позже. В этом случае вы могли бы

  • временно изменить для пользователя на WWW-данные с su,
  • дать доступ wp-content group 775 и присоединиться к группе www-data или
  • предоставьте пользователю права доступа к папке с помощью списков ACL .

Что бы вы ни делали, убедитесь, что файлы имеют права доступа rw для www-данных .


2
Корнел дает одну из таких авторитетных ссылок ниже. См. Также codex.wordpress.org/Changing_File_Permissions , документ Apache httpd.apache.org/docs/2.2/misc/security_tips.html и почти любой поиск Google по этой теме. Но в общем случае, когда вы сомневаетесь, не предоставляете права на запись (и, конечно, нет права собственности) и ослабляете в каждом конкретном случае, а не наоборот (принцип наименьших привилегий, который вы нарушаете здесь).
— Calimo

22
Почему существует функция автоматического обновления, если она не работает даже без изменения разрешений?
— Малхал

6
@ ManuelSchneid3r, я вижу некоторые файлы PHP под wp-контентом, они действительно должны быть доступны для записи www-data??? Это действительно звучит совсем не безопасно.
— Алексис Вилке

12
Это решение не позволит WordPress устанавливать «автоматические обновления безопасности». Вы должны вручную выполнить шаги выше для каждого незначительного обновления WordPress.
— Йерун

11
Это не безопасная конфигурация. Установка разрешений на чтение для этих файлов не влияет, когда пользователь apache также владеет файлами! НЕ ИСПОЛЬЗУЙТЕ. См. Codex.wordpress.org/Changing_File_Permissions
— PodTech.io

60

Предоставление пользователю полного доступа ко всем wp-файлам www-data(в данном случае это пользователь веб-сервера) может быть опасным. Так что скорее НЕ делайте этого:

chown www-data:www-data -R *

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

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

Чтобы защитить ваш сайт от такой атаки, вам необходимо следующее:

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

/

Корневой каталог WordPress: все файлы должны быть доступны для записи только вашей учетной записи пользователя, кроме .htaccess, если вы хотите, чтобы WordPress автоматически генерировал для вас правила перезаписи.

/wp-admin/

Область администрирования WordPress: все файлы должны быть доступны для записи только вашей учетной записи.

/wp-includes/

Основная часть логики приложения WordPress: все файлы должны быть доступны для записи только вашей учетной записи.

/wp-content/

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

Внутри /wp-content/вы найдете:

/wp-content/themes/

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

/wp-content/plugins/

Файлы плагинов: все файлы должны быть доступны для записи только вашей учетной записи.

Другие каталоги, которые могут присутствовать, /wp-content/должны быть задокументированы тем плагином или темой, которые этого требуют. Разрешения могут отличаться.

Источник и дополнительная информация: http://codex.wordpress.org/Hardening_WordPress


вашей учетной записью. означает пользователь, выполняющий сценарии php на сайте (обычно пользователь apache)?
— Шаси Кант

4
@shasikanth Нет, пользователь apache - это тот, кого он называет «процесс веб-сервера». Учетная запись пользователя - это ваш пользователь Linux (ssh, пользователь ftp и т. Д.)
— Daniel Bang

В этом ответе и в принятом ответе должен ли пользователь (не www-данные) входить в группу www-data?
— user658182

1
Нет, в этом весь смысл.
— Петр Наврот

1
Проблема, с которой я сталкиваюсь, заключается в том, что каждый раз, когда я делаю своего пользователя SSH владельцем / wp-content / plugins /, Wordpress становится полностью неработоспособным из-за администраторов, с постоянной процедурой всплывающего окна FTP или ошибками разрешений. Не могу ни добавить, ни обновить плагины. Только когда я делаю www-данные владельцем wp-контента, работает плагин Wordpress Admin. (Пример: sudo chown www-data: www-data -R / var / www / html / wp-content /)
— Heres2u

26

Для тех, у кого есть корневая папка WordPress в домашней папке:

** Ubuntu / Apache

  1. Добавьте вашего пользователя в группу www-data:

КРЕДИТ Предоставление прав на запись для группы www-данных

Вы хотите позвонить usermodсвоему пользователю. Так что это будет:

sudo usermod -aG www-data yourUserName

** Предполагая, что www-dataгруппа существует

  1. Проверьте, что ваш пользователь находится в www-dataгруппе:

    groups yourUserName

Вы должны получить что-то вроде:

youUserName : youUserGroupName www-data

** youUserGroupName обычно похоже на ваше имя пользователя

  1. Рекурсивно меняйте групповое владение папкой wp-content, сохраняя право владения пользователем

    chown yourUserName:www-data -R youWebSiteFolder/wp-content/*

  2. Сменить каталог на youWebSiteFolder / wp-content /

    cd youWebSiteFolder/wp-content

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

    find . -type d -exec chmod -R 775 {} \;

** режим `/ home / yourUserName / youWebSiteFolder / wp-content / 'изменен с 0755 (rwxr-xr-x) на 0775 (rwxrwxr-x)

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

    find . -type f -exec chmod -R 664 {} \;

Результат должен выглядеть примерно так:

WAS:
-rw-r--r--  1 yourUserName www-data  7192 Oct  4 00:03 filename.html
CHANGED TO:
-rw-rw-r--  1 yourUserName www-data  7192 Oct  4 00:03 filename.html

Эквивалентно:

chmod -R ug + rw foldername

Разрешения будут как 664 для файлов или 775 для каталогов.

Ps, если кто-либо сталкивается с ошибкой 'could not create directory'при обновлении плагина, делайте:
server@user:~/domainame.com$ sudo chown username:www-data -R wp-content
когда вы находитесь в корне своего домена.
Предполагая: wp-config.phpимеет
учетные данные FTP на LocalHost
define('FS_METHOD','direct');


10
-1. Вы НЕ хотите, чтобы www-данные имели доступ на запись к файлам WordPress, за исключением wp-контента.
— Calimo

775 в wp-контенте помогает. С 644 для файлов, 755 для папок и chown user: www-data, у меня иногда возникали проблемы с загрузкой медиа, обновлением плагина и т. Д. 775 позволяет изменять wp-контент с помощью www-data: www-data также , который решает проблему.
— guylabbe.ca

Удалите -R из команды find / chmod, поскольку она медленная и ненужная.
— Адам Хименес

20

Лучше всего прочитать документацию WordPress на этом https://wordpress.org/support/article/changing-file-permissions/

  • Все файлы должны принадлежать фактической учетной записи пользователя, а не учетной записи пользователя, используемой для процесса httpd
  • Принадлежность группы не имеет значения, если только нет особых групповых требований для проверки разрешений процесса веб-сервера. Обычно это не так.
  • Все каталоги должны быть 755 или 750.
  • Все файлы должны быть 644 или 640. Исключение: wp-config.php должен быть 440 или 400, чтобы другие пользователи на сервере не могли его прочитать.
  • Не нужно давать 777 каталогов, даже загружать каталоги. Поскольку процесс php запускается как владелец файлов, он получает разрешения владельцев и может записывать даже в каталог 755.

4
Не уверен, почему за вас проголосовали: как будто люди хотят, чтобы главный ответ - как оставить установку небезопасной !
— BCran

Ссылка устарела. новое здесь: wordpress.org/support/article/changing-file-permissions И спасибо, что вы единственный, кто ссылается на фактические документы!
— каждый

Если wp-config.php равен 400, как apache должен включать его (таким образом читать) при загрузке страницы?
— Мартин Браун

14

Я установил разрешения для:

    # Set all files and directories user and group to wp-user
    chown wp-user:wp-user -R *

    # Set uploads folder user and group to www-data
    chown www-data:www-data -R wp-content/uploads/

    # Set all directories permissions to 755
    find . -type d -exec chmod 755 {} \;

    # Set all files permissions to 644
    find . -type f -exec chmod 644 {} \;

В моем случае я создал конкретного пользователя для WordPress, который отличается от пользователя по умолчанию apache, который запрещает доступ из Интернета к файлам, принадлежащим этому пользователю.

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

отредактированный

Если вы используете W3C Total Cache, вы должны также сделать следующее:

rm -rf wp-content/cache/config
rm -rf wp-content/cache/object
rm -rf wp-content/cache/db
rm -rf wp-content/cache/minify
rm -rf wp-content/cache/page_enhanced

Тогда это сработает!

отредактированный

Через некоторое время при разработке сайтов на WordPress я бы порекомендовал разные права доступа к файлам для каждой среды:

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

# Set uploads folder user and group to www-data
chown www-data:www-data -R wp-content/uploads/

www-data: www-data = пользователь и группа apache или nginx

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

Наконец, среда разработки будет иметь доступ к плагинам обновления, переводам, всему, что угодно ...

# Set uploads folder user and group to www-data
chown www-data:www-data -R wp-content/

# Set uploads folder user and group to www-data
chown your-user:root-group -R wp-content/themes

# Set uploads folder user and group to www-data
chown your-user:root-group -R wp-content/plugins/your-plugin

www-data: www-data = пользователь apache или nginx и группа your-user: root-group = ваш текущий пользователь и корневая группа

Эти разрешения предоставят вам доступ к разработке в папке themesи your-pluginпапке без разрешения. Остальная часть контента будет принадлежать пользователю Apache или Nginx, что позволит WP управлять файловой системой.

Перед созданием git-репо сначала запустите эти команды:

# Set all directories permissions to 755
find . -type d -exec chmod 755 {} \;

# Set all files permissions to 644
find . -type f -exec chmod 644 {} \;

11
Нееет! Никогда не делайте 777. Пожалуйста, не советуйте это (новым) людям, читающим это.
— Карло

Никакие файлы или папки не должны принадлежать процессу http - это серьезный пробел в безопасности. Если злонамеренный пользователь обнаружил эксплойт в плагине, теме или самом WordPress, он мог бы загрузить код, который затем можно запустить с помощью Apache, и получить доступ - я видел это на собственном
— опыте

10

Правильные разрешения для файла - 644 Правильные разрешения для папки - 755

Чтобы изменить разрешения, используйте терминал и следующие команды.

find foldername -type d -exec chmod 755 {} \;
find foldername -type f -exec chmod 644 {} \;

755 для папок и 644 для файлов.


1
и 640 для wp-config.php. Но, к сожалению, вам нужно изменить разрешения для папок для загрузки, плагинов и тем на 775, и если вы хотите обновить свой WordPress, вам придется изменить все папки на 775. В этом разделе ваши разрешения будут отображаться с ошибками при обновлении. / изменение плагинов, тем и загрузка медиа.
— эргиндуран

8

Я думаю, что следующие правила рекомендуются для сайта WordPress по умолчанию:

  • Для папок внутри wp-содержимого установите права доступа 0755:

    плагины chmod -R 0755

    chmod -R 0755 загрузок

    chmod -R 0755 обновление

  • Пусть пользователь apache будет владельцем вышеуказанных каталогов wp-контента:

    Чоун Apache загрузки

    апгрейд chown apache

    плагины chown apache


1
Вы также можете рекурсивно устанавливать разрешения для каталогов, например: chown -R apache uploads . И если требуется, вы также можете передать групповое владение apache: chgrp apache uploads
— shasi kanth

8

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

Это назначит «root» (или любого другого пользователя, которого вы используете) как пользователя в каждом отдельном файле / папке, R означает рекурсивный, поэтому он не останавливается на папке «html». если вы не использовали R, то это применимо только к каталогу "html".

sudo chown -R root:www-data /var/www/html  

Это установит владельца / группу «wp-content» на «www-data», что позволит веб-серверу устанавливать плагины через панель администратора.

chown -R www-data:www-data /var/www/html/wp-content

Это установит разрешение для каждого отдельного файла в папке «html» (включая файлы в подкаталогах) равным 644, поэтому посторонние люди не могут выполнить любой файл, изменить любой файл, группа не может выполнить любой файл, изменить любой файл и только пользователю разрешено изменять / читать файлы, но даже пользователь не может выполнить ни один файл. Это важно, потому что это предотвращает любое выполнение в папке «html», а также потому, что владельцем папки html и всех других папок, кроме папки wp-content, являются «root» (или ваш пользователь), www-data может ' • изменить любой файл за пределами папки wp-content, поэтому, даже если на веб-сервере есть какая-либо уязвимость, и если кто-то получил к нему несанкционированный доступ, он не сможет удалить основной сайт, кроме плагинов.

sudo find /var/www/html -type f -exec chmod 644 {} +

Это ограничит разрешение доступа к «wp-config.php» пользователю / группе с rw-r ----- этими разрешениями.

chmod 640 /var/www/html/wp-config.php

И если плагин или обновление жаловались, что он не может обновиться, то получите доступ к SSH и используйте эту команду, а также предоставьте временное разрешение на «www-data» (веб-сервер) для обновления / установки через панель администратора, а затем вернитесь вернуться к «root» или вашему пользователю, как только он будет завершен.

chown -R www-data /var/www/html

А в Nginx (такая же процедура для apache) для защиты папки wp-admin от несанкционированного доступа и зондирования. apache2-utils необходим для шифрования пароля, даже если у вас установлен nginx, пропустите c, если вы планируете добавить больше пользователей в тот же файл.

sudo apt-get install apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd userName

Теперь посетите это место

/etc/nginx/sites-available/

Используйте эти коды для защиты папки «wp-admin» паролем, теперь она спросит пароль / имя пользователя, если вы попытались получить доступ к «wp-admin». обратите внимание, здесь вы используете файл ".htpasswd", который содержит зашифрованный пароль.

location ^~ /wp-admin {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    index  index.php index.html index.htm;
}

Теперь перезапустите nginx.

sudo /etc/init.d/nginx restart

Использование пользователя root не рекомендуется. Это может быть опаснее. Просто создайте нового пользователя и добавьте его в группу sudo
— erginduran

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

2

Команды:

chown www-data:www-data -R *
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Где ftp-пользователь - это пользователь, которого вы используете для загрузки файлов

chown -R ftp-user:www-data wp-content
chmod -R 775 wp-content

1
должно быть выбрано имя пользователя: www-data, иначе вы не можете редактировать файлы
— malhal

Вы можете использовать $(whoami)вместо ftp-user. По умолчанию ваш текущий пользователь ( не root ) является вашим пользователем FTP, если вы используете свой собственный сервер (локальный, vps и т. Д.)
— Juanjo Salvador

2

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

https://en-ca.wordpress.org/plugins/all-in-one-wp-security-and-firewall/

https://en-ca.wordpress.org/plugins/wordfence/

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


2
chown -Rv www-data:www-data
chmod -Rv 0755 wp-includes
chmod -Rv 0755 wp-admin/js
chmod -Rv 0755 wp-content/themes
chmod -Rv 0755 wp-content/plugins
chmod -Rv 0755 wp-admin
chmod -Rv 0755 wp-content
chmod -v 0644 wp-config.php
chmod -v 0644 wp-admin/index.php
chmod -v 0644 .htaccess

1

Я не могу сказать вам, правильно это или нет, но я использую изображение Bitnami через Google Compute App Engine. У меня проблемы с плагинами и миграцией, и после того, как я все испортил с помощью прав доступа chmod, я нашел эти три строки, которые решили все мои проблемы. Не уверен, что это правильно, но сработало для меня.

sudo chown -R bitnami:daemon /opt/bitnami/apps/wordpress/htdocs/
sudo find /opt/bitnami/apps/wordpress/htdocs/ -type f -exec chmod 664 {} \;
sudo find /opt/bitnami/apps/wordpress/htdocs/ -type d -exec chmod 775 {} \;


1

Определите в файле wp_config.

/var/www/html/Your-Project-File/wp-config.php

define( 'FS_METHOD', 'direct' );

chown - меняет владельца файлов / директорий. То есть. владелец файла / dir изменится на указанный, но не изменит разрешения.

sudo chown -R www-data:www-data /var/www

0

Основываясь на прочтении и мучениях на моих сайтах, и после того, как меня взломали, я пришел к приведенному выше списку, который включает разрешения для плагина безопасности для Wordpress под названием Wordfence. (Не связан с этим)

В нашем примере корнем документа WordPress является /var/www/html/example.com/public_html

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

cd /var/www/html/example.com
sudo chown -R www-data:www-data public_html/

Теперь с панели инструментов на вашем сайте, как администратор, вы можете выполнять обновления.

Безопасный сайт после завершения обновлений, выполнив следующие действия:

sudo chown -R wp-user:wp-user public_html/

Приведенная выше команда изменяет права доступа ко всему в установке WordPress для пользователя WordPress FTP.

cd public_html/wp-content
sudo chown -R www-data:wp-user wflogs
sudo chown -R www-data:wp-user uploads

Приведенная выше команда гарантирует, что плагин безопасности Wordfence имеет доступ к своим журналам. Каталог загрузки также доступен для записи по www-данным.

cd plugins
sudo chown -R www-data:wp-user wordfence/

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

Разрешения для каталогов и файлов

# Set all directories permissions to 755
find . -type d -exec chmod 755 {} \;

# Set all files permissions to 644
find . -type f -exec chmod 644 {} \;

Установите разрешения для wp-config.php равными 640, чтобы только wp-пользователь мог читать этот файл, и никто другой. Разрешения 440 не работали для меня с вышеуказанным владельцем файла.

sudo chmod 640 wp-config.php

Автоматические обновления Wordpress с использованием SSH работали нормально с PHP5, но не работали с PHP7.0 из-за проблем с php7.0-ssh2 bundeld с Ubuntu 16.04, и я не мог найти, как установить правильную версию и заставить ее работать. К счастью, очень надежный плагин под названием ssh-sftp-updater-support (бесплатный) делает возможным автоматическое обновление с использованием SFTP без необходимости в libssh2. Таким образом, вышеуказанные разрешения никогда не нужно ослаблять, за исключением редких случаев, когда это необходимо.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.