1

Я размещаю несколько сайтов WordPress на LEMP VPS.

  • Каждый сайт имеет свою собственную установку Wordpress (находится в /srv/http/domain/wordpress), собственную учетную запись пользователя (site-user) и свой собственный пул php-fpm, работающий от имени пользователя сайта.
  • Nginx работает под учетной записью http, и все файлы в /srv/http/domain/wordpress имеют пользователя site-user: владелец http с разрешениями 0640 (файлы) и 2750 (каталоги).

Таким образом, каждый пользователь имеет полный RW- доступ к своим файлам / каталогам, но не имеет доступа к файлам / каталогам других сайтов. Nginx имеет доступ только для R к файлам / каталогам каждого сайта.

Я использую бит setgid, чтобы заставить новые каталоги, созданные в /srv/http/domain/wordpress наследовать группу http, чтобы Nginx имел доступ для чтения к ним. Это работает, как и ожидалось, когда файлы создаются через SFTP.

Это мне кажется нормальным, и я могу успешно обновлять плагины, темы и WordPress через интерфейс wp-admin . Тем не менее, каждый раз, когда я выполняю задачу, требующую, чтобы WordPress создавал новые файлы / каталоги - в основном, каждый раз, когда я устанавливаю или обновляю плагин / тему или обновляю сам Wordpress - в результате владельцем файла становится сайт-пользователь: сайт-пользователь . Я хотел бы, чтобы вновь созданные файлы / каталоги учитывали бит setgid и создавали файлы / каталоги с владельцем сайта: владельцем http, чтобы Nginx мог читать эти файлы без моего вмешательства.

Я установил следующее в файле wp-config.php каждого сайта:

  • define( 'FS_CHMOD_DIR', ( 02750 & ~ umask() ) );
  • define( 'FS_CHMOD_FILE', ( 0640 & ~ umask() ) );

Это заставляет права доступа к тому, что я хочу, но не влияет на владение.

Я читал это и это, но "решение" требует изменения кода PHP, чтобы избежать использования move_uploaded_file() что хорошо, если вы пишете свой собственный код PHP, но я не собираюсь начинать изменять файлы PHP WordPress. Я даже не уверен, что это источник моей проблемы.

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

Как контролировать владение файлами, созданными WordPress/PHP?

|источник

1 ответ1

1

Я нашел пару решений для этого:

  1. Новые файлы, созданные Wordpress (на самом деле PHP), определяются пользователем с помощью групповых директив в файле конфигурации пула php-fpm, в которых выполняется PHP. Таким образом, чтобы заставить вновь созданные файлы принадлежать сайту-пользователю: владение http, как я изначально надеялся, вы можете просто установить user = site-user и group = http в вашем файле конфигурации php-fpm для вашего сайта. Это работает в том, что вновь созданные файлы имеют владельца группы, которую я искал. Однако с точки зрения безопасности это частично противоречит цели создания отдельных пулов php-fpm для каждого сайта, поскольку любой пользователь сайта может потенциально создавать файлы PHP, которые будут иметь доступ для чтения к файлам / каталогам другого сайта.

  2. Проще и безопаснее, чем вышеописанный # 1, это иметь все файлы / каталоги сайта, принадлежащие site-user:site-user (вместо site-user:http, как я изначально планировал), а затем добавить пользователя http в сайт- группа пользователей . С разрешениями 640 (файлы) и 750 (папки) на всех сайтах это фактически дает nginx доступ только для чтения к файлам каждого сайта по мере необходимости, но при этом запрещает любому пользователю читать файлы любого другого сайта, кроме своих собственных.

Вариант № 2, описанный выше, не требует использования бита setgid, что упрощает работу, но требует добавления следующего в ваш файл wp-config.php :

  • define( 'FS_CHMOD_DIR', ( 0750 & ~ umask() ) );
  • define( 'FS_CHMOD_FILE', ( 0640 & ~ umask() ) );

Без вышеприведенных строк WordPress/PHP создаст общедоступные файлы (644) и папки (755).

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .