Права доступа приложения

Наверное верная и коротко написано здесь, а ниже я сохранил мои размышления из прошлого.

Когда вы используете веб-сервер (например Apache или Nginx), то этот сервер работает от пользователя www-data, но команды в консоли вы обычно выполняете от другого пользователя (например vasya), вот тут и возникает проблема. Заключается проблема в том, что пользователь www-data создает файлы, которые пользователь vasya не может изменить/удалить. На этот счет есть ряд ниже изложенных решений. И сразу опишу решение:

  1. добавьте себя в группу www-data: sudo adduser $(whoami) www-data && newgrp www-data
  2. укажите приложению umask 002, например для php-fpm: echo "umask=0002" >> /usr/local/etc/php-fpm.conf

А теперь ниже опишу, почему такое решение правильное.

Общая группа

Правильное решение:

  • добавить пользователя vasya в группу www-data.

Неправильные решения:

  • выполнять консольные команды от пользователя www-data (иногда, у консольного пользователя должно быть немного больше прав, например чтобы сохранять данные в определенные директории, недоступные пользователю www-data)
  • сделать так, чтобы веб-сервер (например Apache или Nginx) работал от пользователя vasya (решение совсем ужасное потому, что если в приложении веб-сервер-а или его модуле будет уязвимость, то оно получит права пользователя vasya, а мы ведь знаем, что у vasya много прав, например полный доступ по ssh)

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

Without ACL

Вариант 1

В Linux можно для создаваемых директорий/файлов задавать права доступа по умолчанию, например хорошей практикой будет задать права в файле /etc/profile, просто добавив строку:

umask 002

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

К сожалению, файлы созданные другими процессами, такими как веб-сервер, по-прежнему будут использовать значение по умолчанию (если не настроено иное).  Например чтобы apache использовал другую umask, мы можем определить это внутри /etc/apache2/envvars (системы debian и ubuntu) или /etc/sysconfig/httpd (системы rhel,centos) подобным образом:

umask 002

и перезагрузите apache, чтобы включить его.

Заметка 1: для php-fpm простой способ: echo "umask=0002" >>  /usr/local/etc/php-fpm.conf 

Заметка 2: обычно в современных дистрибутивах Linux это значение по умолчанию равно 022, вы можете проверь это выполнив команду:

umask

Вариант 2

Измените umask так, чтобы каталоги/файлы которые создает PHP, были доступны независимо от того, создает их пользователь веб-сервера и пользователь командной строки. Добавьте в начале bin/console или web/app.php:

umask(0002); // This will let the permissions be 0775

// or

umask(0000); // This will let the permissions be 0777

ПРИМЕЧАНИЕ: изменение umask не является потокобезопасным.

With ACL

Проблемный вариант, подробности в конце статьи.

Using ACL on a System that Supports chmod +a (macOS)

On macOS systems, the chmod command supports the +a flag to define an ACL. Use the following script to determine your web server user and grant the needed permissions:

rm -rf var/cache/*
rm -rf var/logs/*

HTTPDUSER=$(ps axo user,comm | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx' | grep -v root | head -1 | cut -d\ -f1)
sudo chmod +a "$HTTPDUSER allow delete,write,append,file_inherit,directory_inherit" var
sudo chmod +a "$(whoami) allow delete,write,append,file_inherit,directory_inherit" var

Using ACL on a System that Supports setfacl (Linux/BSD)

Most Linux and BSD distributions don't support chmod +a, but do support another utility called setfacl. You may need to install setfacl and enable ACL support on your disk partition before using it. Then, use the following script to determine your web server user and grant the needed permissions:

HTTPDUSER=$(ps axo user,comm | grep -E '[a]pache|[h]ttpd|[_]www|[w]ww-data|[n]ginx' | grep -v root | head -1 | cut -d\ -f1)

# if this doesn't work, try adding '-n' option

sudo setfacl -dR -m u:"$HTTPDUSER":rwX -m u:$(whoami):rwX var
sudo setfacl -R -m u:"$HTTPDUSER":rwX -m u:$(whoami):rwX var

NOTE: The first setfacl command sets permissions for future files and folders, while the second one sets permissions on the existing files and folders. Both of these commands assign permissions for the system user and the Apache user.

setfacl isn't available on NFS mount points. However, storing cache and logs over NFS is strongly discouraged for performance reasons.

На практике права, выставленные описанным выше способом, постепенно начинают «слетать» сами собой. В частности, пропадают права на запись в папки. С этим я столкнулся при автоматическом деплойменте кода сайтов с гитлаба. Поначалу всё шло хорошо. Затем rsync, который я использовал для синхронизации извне, стал жаловаться на недоступность некоторых файлов на запись. Я долго не мог понять, в чём дело, но в один прекрасный день просто решил пройтись по папкам getfacl-ом и обнаружил, что дефолтные права пользователя отсутствуют, а ведь я ничего на сервере не менял:

user::rw-
group::r--
other::r--

Вероятно, это связано с тем, что rsync копирует директории без ключа -p (а ведь в мануале к acl сказано, что при копировании аргумент -p обязателен).

Источник: 1 - 2 - 3 - 4 - 5 - 6 - 7

29.11.2018 11:22