Перейти к содержанию

Права доступа

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

Сначала выясните, под каким пользователем работает Apache или Nginx, выполнив команду Для Apache:

ps aux | grep -v root | grep apache | cut -d\  -f1 | sort | uniq

Для Nginx:

ps aux | grep -v root | grep nginx | cut -d\  -f1 | sort | uniq

И выясните, какому пользователю принадлежат файлы в папке Grav, выполнив

ls -l

Будучи файловой CMS, Grav должен записывать данные в файловую систему, чтобы создавать кэш и файлы журналов. Есть три основных сценария:

  1. PHP/веб-сервер работает под тем же пользователем, что редактирует файлы. (Предпочтительно)

    Этот подход используется в большинстве конфигураций общего хостинга и хорошо работает при локальной разработке. В нашей записи блога о MacOS Yosemite, Apache и PHP описано, как настроить Apache, чтобы он работал под вашей личной учётной записью. Этот подход считается недостаточно безопасным для выделенного веб-хоста, поэтому стоит использовать второй или третий вариант.

  2. PHP/веб-сервер работает под разными учётными записями, но в одной группе

    Если использовать общую группу для вашей учётной записи и учётной записи PHP/веб-сервера с правами 775 и 664, вы гарантируете, что, несмотря на две разные учётные записи, обе будут иметь доступ на чтение и запись к файлам. Ещё, вероятно, стоит задать umask 0002 в корне, чтобы новые файлы создавались с правильными правами.

  3. Разные учётные записи, права исправляются вручную

    Последний подход — полностью разные учётные записи, и после редактирования вы просто обновляете владельца и права файлов, чтобы пользователь PHP/веб-сервера мог читать и записывать как нужно.

Для этого можно использовать простой shell-скрипт исправления прав:

1
2
3
4
5
6
#!/bin/sh
chown -R joeblow:staff .
find . -type f -exec chmod 664 {} \;
find ./bin -type f -exec chmod 775 {} \;
find . -type d -exec chmod 775 {} \;
find . -type d -exec chmod +s {} \;

Вы можете взять этот файл и отредактировать его под нужного пользователя и группу для вашей конфигурации. По сути, скрипт делает следующее:

  1. Меняет владельца текущей папки, всех файлов и подпапок на joeblow и staff.
  2. Находит все файлы от текущей папки вглубь и ставит права 664: RW для пользователя и группы и R для остальных.
  3. Находит все папки от текущей папки вглубь и ставит права 775: RWX для пользователя и группы и RX для остальных.
  4. Устанавливает владельца всех папок, чтобы сохранять изменения пользователя и группы.

Права на папку кэша изображений

Если файлы изображений в папке кэша записываются с неверными правами, попробуйте задать в файле user/config/system.yaml,

1
2
images:
  cache_perms: '0775'

если свойство images уже есть, просто добавьте cache_perms: '0775' в его конец.

Если это не помогло, создайте файл setup.php в корне Grav (там же, где index.php) и добавьте

1
2
<?php
umask(0002);

в него.

Если файл setup.php уже есть, просто добавьте эту строку в начало. Этот файл обычно используется для настройки мультисайта, но поскольку он вызывается при каждом обращении к Grav, его можно применять и для других целей.

Совместный хостинг с сайтом WordPress

В целом Grav можно установить в папку верхнего уровня существующего сайта WordPress, и две CMS прекрасно уживутся. (Не забудьте задать Base Rewrite в htaccess папки Grav.) Если при работе с админкой и/или просмотре страниц Grav возникают ошибки прав доступа к файлам кэша, проверьте, установлен ли для этого сайта WordPress сервис WP-Engine. Если да, обратитесь в их поддержку, чтобы для папки Grav сделали исключение в их агрессивном сервисе распределённого кэширования.

Советы для SELinux

Если предложенное выше всё ещё не работает, выполните в корневой папке Grav

chcon -Rv system_u:object_r:httpd_sys_rw_content_t:s0 ./.

Источники: - https://unix.stackexchange.com/questions/337704/selinux-is-preventing-nginx-from-writing-via-php-fpm - https://github.com/getgrav/grav/issues/912#issuecomment-227627196 - http://stopdisablingselinux.com - http://stackoverflow.com/questions/28786047/failed-to-open-stream-on-file-put-contents-in-php-on-centos-7 - http://www.serverlab.ca/tutorials/linux/web-servers-linux/configuring-selinux-policies-for-apache-web-servers/