Правильные файловые права для 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.