Правильные файловые права для WordPress

312

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

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

  • корневая папка, сохраняющая весь контент WordPress
  • сор-администратора
  • сор-контента
  • WP-включает в себя

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

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

15 ответов

323
Лучший ответ

При настройке 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-content должен быть доступен для записи только вашей учетной записью пользователя. wp-контент должен быть доступен для записи через www-data.

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

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

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

Независимо от того, что вы делаете, убедитесь, что у файлов есть rw-разрешения для www-данных.

  • 0
    Правдоподобно, если wp действительно нужен только wpcontent. Есть ли у вас какие-либо ссылки для обоснования вашей диссертации? Это ТАК не просто болтовня. До сих пор ваш комментарий просто напыщенный.
  • 2
    Корнел дает одну из таких авторитетных ссылок ниже. См. Также codex.wordpress.org/Changing_File_Permissions , документ Apache httpd.apache.org/docs/2.2/misc/security_tips.html и почти любой поиск Google по этой теме. Но в общем случае, когда вы сомневаетесь, не предоставляете права на запись (и, конечно, нет права собственности) и ослабляете в каждом конкретном случае, а не наоборот (принцип наименьших привилегий, который вы нарушаете здесь).
Показать ещё 13 комментариев
47

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

chown www-data:www-data -R *

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

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

Чтобы защитить свой сайт от такой атаки, вы должны:

Все файлы должны принадлежать вашей учетной записи пользователя и должны быть доступны для записи тобой. Любой файл, который требует доступа на запись из 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

  • 0
    вашей учетной записью. означает пользователя, выполняющего сценарии php на сайте (обычно пользователь apache)?
  • 3
    @shasikanth Нет, пользователь apache - это тот, кого он называет «процесс веб-сервера». Учетная запись пользователя - это ваш пользователь Linux (ssh, ftp user и т. Д.)
Показать ещё 5 комментариев
20

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

** Ubuntu/apache

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

CREDIT Предоставление разрешений на запись в группу www-data

Вы хотите вызвать 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 имя папки

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

P.s. если кто-то сталкивается с ошибкой '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');

  • 7
    -1. Вы НЕ хотите, чтобы www-данные имели доступ для записи к файлам WordPress, за исключением wp-контента.
  • 0
    775 в wp-контенте помогает. С 644 для файлов, 755 для папок и chown user: www-data, у меня иногда возникали проблемы с загрузкой медиа, обновлением плагина и т. Д. 775 позволяет изменять wp-контент с помощью www-data: www-data также , который решает проблему.
Показать ещё 1 комментарий
13

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

    # 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 обрабатывать папку для загрузки и, наконец, устанавливать достаточно безопасные разрешения для файлов и папок.

EDITED

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

chmod 777 wp-content/w3tc-config
chmod 777 wp-content/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

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

EDITED

Через некоторое время, разрабатывая сайты 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

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

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

# 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 ваш пользователь: 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 {} \;
  • 3
    Нееет! Никогда не делайте 777. Пожалуйста, не советуйте это (новым) людям, читающим это.
9

Правильные разрешения для файла - 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. В этом разделе ваши разрешения будут отображаться с ошибками при обновлении. / изменение плагинов, тем и загрузка медиа.
7

Лучше всего прочитать документацию Wordpress на этом https://codex.wordpress.org/Changing_File_Permissions

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

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

  • Для папок внутри wp-контента установите разрешения 0755:

    chmod -R 0755 плагины

    chmod -R 0755 загружает

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

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

    chown apache uploads

    обновление chown apache

    chown apache plugins

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

Фактически это зависит от плагинов, которые вы планируете использовать, поскольку некоторые плагины меняют корневой документ 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 может " t изменять любой файл вне папки 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
  • 0
    Использование пользователя root не рекомендуется. Это может быть опаснее. Просто создайте нового пользователя и добавьте его в группу sudo.
  • 0
    Я не защищал здесь, чтобы использовать рут. Я использовал рут в качестве примера. Вы можете использовать любое имя вместо рута.
3

Команды

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
  • 0
    должно быть выбрано имя пользователя: www-data, иначе вы не сможете редактировать файлы
  • 0
    Вы можете использовать $(whoami) вместо ftp-user . По умолчанию ваш текущий пользователь ( не root ) является вашим пользователем FTP, если вы используете свой собственный сервер (локальный, vps и т. Д.)
1

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

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

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

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

1

Для OS X используйте эту команду:

sudo chown -R www:www /www/folder_name
1

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

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 {} \;
0

Определите в файле 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 document является /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 install на пользователя Wordpress FTP.

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

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

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

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

Разрешения для каталогов и файлов # Установите все разрешения на каталоги для 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 с Ubuntu 16.04, и я не мог найти, как установить правильную версию и заставить ее работать. К счастью, очень надежный плагин под названием ssh-sftp-updater-support (бесплатно) делает автоматические обновления с использованием SFTP без необходимости в libssh2. Таким образом, вышеупомянутые разрешения никогда не должны быть ослаблены, за исключением редких случаев по мере необходимости.

0
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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню