Права пользователей на сервере: пример для веб-приложения

На сервере с веб-приложением опасно запускать сервис от имени администратора: ошибка в приложении тогда может открыть доступ ко всему, что доступно root. Разберём пример для Debian 12: пользователь deploy выкладывает релизы, а отдельный пользователь catalog запускает сервис и пишет данные только в каталог загрузок.

Что настраиваем

Сценарий рассчитан на сервер, где вы уже вошли под пользователем с правом выполнять команды через sudo. Приложение установлено в /srv/catalog/releases, пользователь deploy отвечает за файлы релиза, а сервис запускается от имени catalog. Загруженные пользователями файлы хранятся отдельно — в /var/lib/catalog/uploads.

Принцип разделения простой: приложение может читать код, но не менять его; deploy может обновлять код; каталог загрузок доступен приложению для записи. Root нужен только для административных операций. Если у вас другой дистрибутив, проверьте названия системных групп и расположение исполняемых файлов: команды ниже приведены для Debian 12.

Право на запись в каталог с кодом — это не удобство деплоя, а полномочие менять то, что будет исполняться.

Создаём пользователей и группу

Общая группа catalog даст deploy доступ к файлам релиза, а самому приложению позволит читать их. У сервисного пользователя не будет домашнего каталога и интерактивной оболочки: входить на сервер для работы с ним не нужно.

sudo groupadd catalog
sudo useradd --create-home --shell /bin/bash deploy
sudo useradd --system --no-create-home --shell /usr/sbin/nologin catalog
sudo usermod --append --groups catalog deploy
sudo usermod --append --groups sudo deploy

Последняя команда добавляет deploy в группу sudo. Выполняйте её только если этому пользователю действительно нужно администрировать сервер; для обычного выкладывания файлов такое право избыточно. Если группа catalog уже существует, первая команда завершится ошибкой — проверьте существующую группу, а не создавайте вторую с другим именем.

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

id deploy

В выводе должна быть группа catalog. Если вы не хотите давать deploy административные права, пропустите добавление в sudo; создание пользователей и каталогов тогда выполняйте из существующей административной учётной записи.

Разделяем код и данные

Создадим каталоги и зададим владельцев. Релизы принадлежат deploy и группе catalog: владелец может обновлять их, а сервисный пользователь получает доступ на чтение и проход по каталогам. Каталог загрузок принадлежит самому сервису, поэтому приложение сможет туда писать.

sudo install -d -o deploy -g catalog -m 0750 /srv/catalog/releases
sudo install -d -o catalog -g catalog -m 0750 /var/lib/catalog/uploads

Когда deploy загрузит релиз, задайте для его каталогов владельца и права доступа:

sudo chown -R deploy:catalog /srv/catalog/releases
sudo find /srv/catalog/releases -type d -exec chmod 0750 {} +
sudo find /srv/catalog/releases -type f -exec chmod 0640 {} +

Права 0750 означают: владелец может читать, менять и проходить по каталогу; группа — читать и проходить; остальные не имеют доступа. Для файлов 0640 разрешает запись владельцу и чтение группе. Не применяйте эти значения вслепую к исполняемым файлам: если приложению нужны запускаемые скрипты, сохраните для них право исполнения и проверьте конкретный способ запуска.

Проверить, что разделение работает, можно от имени сервиса и deploy:

sudo -u catalog test -r /srv/catalog/releases
sudo -u catalog test ! -w /srv/catalog/releases
sudo -u catalog test -w /var/lib/catalog/uploads
sudo -u deploy test -w /srv/catalog/releases

Команды не печатают сообщение при успехе. Если проверка не пройдена, команда завершится с ненулевым кодом. Первые две проверки подтверждают, что catalog может читать релизы, но не менять их; третья — что сервис может писать загрузки; четвёртая — что deploy может обновлять код.

Сравниваем три схемы доступа

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

ACL — списки дополнительных правил доступа к файлам: они позволяют выдать права отдельному пользователю или группе сверх стандартной схемы «владелец — группа — остальные».

Что ломается на практике

Сервис не читает новый релиз

Частая причина — каталог создали до настройки группы или загрузили файлы с владельцем, которому сервис не принадлежит. Проверьте цепочку каталогов: для чтения файла пользователю нужны права прохода на каждый родительский каталог. Команды namei -l /srv/catalog/releases и id catalog покажут права по пути и группы пользователя.

Приложение не может сохранить загрузку

Проверьте владельца и режим каталога командой stat -c '%U:%G %a %n' /var/lib/catalog/uploads. Ожидаемый результат для примера — catalog:catalog и 750. Если приложение пишет не туда, сначала найдите фактический путь в конфигурации самого приложения; не исправляйте ошибку выдачей права на запись всему дереву /srv.

После деплоя права снова неправильные

Архив или инструмент копирования может сохранить владельца и режимы из источника. После каждой публикации проверьте владельца и права нового релиза. Не запускайте всю сборку от root ради исправления одной ошибки доступа: так файлы могут остаться недоступными обычному пользователю деплоя.

Пользователь попал не в ту группу

Добавление в группу действует для новых сеансов. Завершите сеанс deploy и войдите снова, затем выполните id deploy. Не меняйте права на 0777 как обходной путь: это разрешает запись всем локальным пользователям и маскирует настоящую причину.

Когда выбирать другую схему

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

Не добавляйте сервисного пользователя в sudo и не давайте ему права на запись в каталог релизов «на всякий случай». Если приложению действительно нужно менять файлы кода, выясните, зачем: часто речь о кэше, сессиях или загрузках, которым нужно отдельное место вне каталога релиза.

Что проверить дальше

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

Следующий шаг — настроить службу так, чтобы она запускалась от пользователя catalog, а временные файлы и загрузки хранила вне каталога с кодом. Конкретные параметры зависят от способа запуска приложения; сверяйте их с документацией systemd и самого приложения. Здесь разбирались только пользователи, группы и права на файлы, а не настройка службы.