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

23 дек. 2010 г., 10:43:50

Просмотры: 11.8K

Голосов: 5

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

Немного контекста:

веб-сервер и PHP fcgi демоны работают от пользователя www-data:www-data
WordPress установлен в /home/blaenk/sites/domain.tld/

Сначала я прочитал, что все файлы/папки должны принадлежать моему пользователю (blaenk) и быть доступными для записи моим пользователем. Но это не сработало. После многих часов исследований, кто-то в IRC-канале посоветовал мне установить владельца всего как www-data:www-data, и это сработало. Меня больше не спрашивали FTP-данные, и установка плагинов работала автоматически.

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

Вопрос

Я уже знаю, что файлы должны иметь права 644, а директории - 755. Однако проблема скорее в владении файлами. Я не хочу устанавливать www-data:www-data для всего в моей установке WordPress, поэтому мне интересно, какие именно файлы/директории требуют такого уровня владения?

ОБНОВЛЕНИЕ: Я полагаю, что на моем shared-хостинге WordPress работает корректно, несмотря на то что все файлы принадлежат моему пользователю, потому что хостинг использует suexec, который, предположительно, запускает PHP от моего имени. Другими словами, файлы фактически принадлежат веб-серверу.

Jorge Israel Peña

275

разрешения автоматические обновления

Комментарии

IMHO вопрос выходит за рамки прав и затрагивает тему владения — классические пользователи ´ftpuser´ и ´wwwuser´, как это (справедливо) настроено на большинстве серверов Apache. Здесь, конечно, есть несколько путей решения... Так какой же «лучший практический подход в WP», наиболее строгое сочетание: какая (под)папка какому пользователю с какими правами...?

Frank N

5 мая 2015 г. 13:37:12

Очевидно, есть несколько этапов: 1) Файл загружается (инициируется php, то есть пользователем ´wwwuser´), но с точки зрения прав это FTP-операция(?), 2) файл распаковывается (права на создание у ´wwwuser´), 3) старые файлы перезаписываются (при первоначальной загрузке почти наверняка принадлежат ftpuser...) ► возможно, стоит включить очень подробное логирование PHP и, конечно, ('WP_DEBUG', true), чтобы отловить все «жалобы» и разобраться с ними по одной?

Frank N

5 мая 2015 г. 13:38:51

Все ответы на вопрос

Насколько я понимаю, это не связано с конкретными разрешениями — для автоматического обновления в целом требуется, чтобы владелец файлов совпадал с пользователем, под которым работает Apache. Если это не так, система переключается на другие методы работы с файловой системой (FTP, SSH) и запрашивает пароль.

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

См. Константы обновления WordPress в Кодексе.

Rarst

100K

23 дек. 2010 г. 10:59:49

Комментарии

Спасибо, Rarst. Я видел ту статью в codex, однако я абсолютно не хочу использовать FTP/SSH. Причина в том, что на shared-хостинге, где я вручную установил WordPress, всё работает, несмотря на то, что все файлы принадлежат моему пользователю. Файлы принадлежат моему пользователю, но также и другой группе, которую я не создавал, поэтому я предполагаю, что здесь используется что-то вроде SETGUID, и, вероятно, именно поэтому процесс веб-сервера может выполнять автоматическое обновление.

Jorge Israel Peña

23 дек. 2010 г. 11:13:15

Моя догадка — в вашей другой конфигурации используется suexec, поэтому Apache запускает WordPress под вашей учётной записью, и нет несоответствия прав.

Rarst

23 дек. 2010 г. 11:21:19

Ха-ха, да, я об этом и говорил. Но всё равно отдам вам балл, раз уж вы единственный, кто ответил. Спасибо :)

Jorge Israel Peña

23 дек. 2010 г. 11:29:08

Прошло даже меньше часа с момента вашего вопроса, и пока нет идеального ответа — либо нужно сопоставлять пользователей, либо использовать FTP/SSH. Кстати, вместо того чтобы добавлять решение в ваш вопрос, не могли бы вы оформить его как ответ с ссылками по теме и тому подобное? Так другие смогут воспользоваться этим в будущем.

Rarst

23 дек. 2010 г. 11:34:08

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

Jorge Israel Peña

23 дек. 2010 г. 11:38:55

Показать остальные 1 комментариев

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

Традиционно в PHP пользователь PHP (также известный как apacheuser, webuser или cgideamon) не имеет прав на изменение файлов — это может делать только пользователь FTP (или «ваша учетная запись» в некоторых описаниях Codex), чтобы усложнить злоумышленникам изменение скриптов.

Что, конечно, делает невозможным обновление PHP-файлов средствами PHP. Поэтому в PHP-среде распространена практика смены владельца файлов с FTP-пользователя на пользователя PHP. Перед этим стоит учесть, что «обновление» происходит в «FTP-режиме» (поскольку вы предоставляете учетные данные). Затем распаковка загруженных архивов может снова выполняться скриптами... ну и, конечно, есть папка wp-content, которую также изменяют и наполняют с помощью PHP-скриптов... (думаю, мы все сталкивались с этой проблемой в WordPress). Всё может стать сложным.

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

Под user account подразумевается именно FTP-аккаунт (а не cgi-демон/пользователь PHP/...).

Frank N

465

24 нояб. 2014 г. 18:29:35

Предполагая, что у вас есть SSH-доступ, сначала определите пользователя. Часто веб-сервер работает от имени пользователя www-data, но если вы не уверены, выполните команду top — там вы увидите пользователя (USER) для процессов PHP, Nginx и др.
Этот шаг очевиден, но найдите, где расположены ваши файлы. Обычно они находятся в /home/www-data/, но я заметил, что Nginx по умолчанию может использовать другой каталог (сейчас не вспомню какой). В любом случае, перейдите (cd) в директорию, где хранятся все ваши домены.
chown -R www-data:www-data example.com — эта команда рекурсивно меняет владельца всех файлов в директории example.com. Скорее всего, это ничего не сломает.

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

Jay Brunet

570

3 июл. 2018 г. 07:31:54

Jorge Israel Peña 275 · Accepted Answer · 2010-12-23T11:43:35

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

Я почти уверен, что это связано с тем, что мой shared-хостинг использует suexec, который по сути запускает скрипты от имени моего пользователя. То есть, файлы на shared-хостинге действительно принадлежали «веб-серверу» (а точнее, CGI-демону).

На моём VPS работает nginx и php-fpm, поэтому у меня нет доступа к Apache suexec. Однако я просто настроил php-fpm на запуск от своего пользователя, чтобы проверить свою теорию, и это действительно сработало — всё функционировало гладко, несмотря на то, что файлы принадлежали мне. Думаю, это может считаться угрозой безопасности (не уверен), поэтому я изучу этот вопрос подробнее, чтобы найти способ избежать запуска php-fpm от своего пользователя. Но теперь я хотя бы понимаю, в чём была проблема!