Права и пользователи на сервере: ошибки новичков

Почему права на сервере ломаются

На Ubuntu Server 24.04 сайт перестаёт читать загруженные файлы, хотя они лежат на месте, или приватный каталог внезапно становится доступен всем локальным пользователям. Часто причина — не в приложении, а в одной команде вроде chmod -R 777 или в том, что файлы создали от имени root. Ниже — ошибки, которые можно проверить и исправить без раздачи лишних прав.

Команды рассчитаны на Ubuntu Server 24.04 и обычную оболочку Bash. Для изменения системных пользователей нужен доступ через sudo. В примерах замените deploy, www-data и пути на значения своего сервера. Сначала убедитесь, что указали правильный путь: рекурсивная команда применится ко всему, что находится внутри него.

1. Выдавать всем полный доступ через chmod 777

Число 777 означает, что владелец, группа и остальные пользователи могут читать, изменять и запускать объект. Для обычного каталога это позволяет любому локальному аккаунту менять его содержимое. Для веб-приложения такая команда обычно не решает проблему надёжно: она маскирует неверного владельца или группы и расширяет доступ дальше, чем нужно.

Сначала посмотрите владельца и права:

ls -ld /var/www/example
ls -l /var/www/example

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

Не запускайте chmod -R на всём /var/www без проверки. Внутри могут быть загрузки, секреты и каталоги, которым нужны разные права.

2. Путать владельца, группу и режим доступа

Владелец — конкретный пользователь, группа — набор пользователей, которым можно дать общий доступ, а режим определяет права владельца, группы и остальных. Например, в записи drwxr-x--- владелец может читать, менять и открывать каталог; группа — читать и открывать; остальные не имеют доступа.

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

namei -l /var/www/example/config.php

Команда покажет владельцев и режим доступа каждого компонента пути. Если проверяете доступ от имени веб-процесса, сверяйте его пользователя и группы через настройки сервиса, а не угадывайте по названию сайта.

Правильное исправление начинается с вопроса «какому процессу нужно какое действие?», а не с команды, которая открывает доступ всем.

3. Менять режим, когда нужно сменить владельца

chmod меняет права, но не владельца. За владельца и группу отвечает chown. Если файл создал root, приложение может не суметь обновить его даже при режиме, который выглядит подходящим. Проверьте владельца:

stat -c '%U:%G %a %n' /var/www/example/storage

Если подтверждено, что каталог должен принадлежать пользователю приложения и группе веб-сервера, исправьте именно этот путь:

sudo chown -R deploy:www-data /var/www/example/storage

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

4. Раздавать sudo без понимания последствий

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

На Ubuntu членство в группе sudo обычно даёт право запускать команды через sudo. Проверить группы текущего пользователя можно так:

id

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

5. Создать пользователя, но забыть о его окружении

Создание учётной записи и настройка входа — не одно и то же. Перед тем как выдавать доступ, решите, нужен ли интерактивный вход, домашний каталог и доступ по SSH. Для сервисного процесса отдельный системный пользователь часто безопаснее обычного аккаунта с оболочкой: приложению не нужен вход человека в систему.

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

Как разбирать ошибку доступа

1. Зафиксируйте точный путь. Не исправляйте права по одному только сообщению «Permission denied». Проверьте каталог и файл, к которому обращается процесс.
2. Узнайте пользователя процесса. Посмотрите конфигурацию сервиса и его статус. Не предполагайте, что веб-сервер и приложение работают под одним аккаунтом.
3. Проверьте каждый уровень пути. Используйте namei -l и ls -ld, чтобы увидеть владельцев и права каталогов.
4. Исправьте минимально необходимое. При неверном владельце меняйте владельца; при неверной группе — группу; при нехватке чтения или прохода — соответствующий режим доступа.
5. Проверьте от имени нужного процесса. Повторите операцию приложения или перезапустите проверку сервиса. Убедитесь, что исправление не открыло доступ посторонним.

Если проблема затрагивает только новые файлы, проверьте, какой пользователь их создаёт и какие права задаёт приложение. Исправление существующего каталога не гарантирует, что следующий деплой не создаст файлы от root снова.

Что выбрать: владелец, группа или права

Что делать дальше

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

Термин: принцип наименьших привилегий — подход, при котором пользователь или процесс получает только те права, которые нужны для его задачи.

Смежная тема — настройка SSH-ключей и ограничение входа по SSH; здесь разбирались только локальные пользователи и права на файлы.