Как настроить права на файлы сайта для Nginx без chmod 777

Для раздачи статического сайта Nginx должен открыть HTML, CSS, JavaScript и изображения, но не обязан их изменять. Удобная модель выглядит так: файлы принадлежат пользователю, который публикует сайт, а остальные процессы могут только читать их. Режим 777 для этого не нужен.

Инструкция относится к каталогу с готовыми статическими файлами, например /var/www/example.org/html. Не применяйте команды рекурсивно к домашнему каталогу, всей /var/www или данным WordPress: у динамических приложений есть отдельные каталоги, куда процесс действительно должен записывать файлы.

Кто пытается открыть файл

В Linux каждая программа работает от имени пользователя. Главная часть Nginx запускается с административными правами, чтобы открыть системные порты, но запросы посетителей обслуживают рабочие процессы с ограниченными правами. Именно их пользователь читает файлы сайта.

На Ubuntu пакет Nginx обычно использует имя www-data, но его лучше проверить на конкретном сервере. Выполните:

ps -o user,group,comm -C nginx

Команда ps показывает запущенные процессы. Параметр -C nginx оставляет только Nginx, а -o задаёт три понятных столбца: пользователь, группа и имя программы. В выводе обычно есть один процесс root и несколько процессов www-data. Для чтения файлов важен ограниченный пользователь www-data.

Если Nginx в списке отсутствует, сначала проверьте его состояние через systemctl status nginx. Изменять права предполагаемому пользователю до запуска службы бессмысленно.

Как Linux решает, разрешить ли чтение

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

• r — прочитать файл или список имён в каталоге;
• w — изменить файл или создавать и удалять элементы каталога;
• x — запустить обычный файл, а для каталога — пройти внутрь по известному имени.

Чтобы Nginx прочитал /var/www/example.org/html/index.html, ему нужно право x на каждом каталоге пути и право r на самом index.html. Поэтому открытый файл всё равно может вернуть ошибку, если один из родительских каталогов закрыт.

Числовые режимы складываются из r = 4, w = 2 и x = 1. Число 755 означает: владелец может читать, изменять и проходить, остальные — читать и проходить. 644 даёт владельцу чтение и запись, а остальным — только чтение.

Посмотрите права на всём пути к странице

Команда namei раскладывает полный путь на отдельные каталоги и конечный файл. Она ничего не меняет. Подставьте путь к реальному index.html:

namei -l /var/www/example.org/html/index.html

Параметр -l добавляет права, владельца и группу каждого элемента. Читайте результат сверху вниз. У каталогов /var, /var/www, /var/www/example.org и html для пользователя Nginx должен быть доступен проход x; у конечного файла — чтение r.

Строка вида drwxr-xr-x admin admin html означает каталог: первая буква d обозначает его тип, владелец admin может изменять содержимое, а группа и остальные могут читать список и проходить внутрь. Строка -rw-r--r-- admin admin index.html означает обычный файл, который изменяет владелец, а остальные только читают.

Если путь проходит через домашний каталог с режимом 700, не открывайте весь домашний каталог ради Nginx. Перенесите публичные файлы в /var/www или /srv, где можно задать отдельные права без раскрытия личных файлов пользователя.

Назначьте владельцем пользователя публикации

В простом примере сайт обновляет пользователь admin, а Nginx читает файлы как www-data. Сначала убедитесь, что команда относится только к готовому статическому сайту. Просмотрите цель через ls -la /var/www/example.org/html и только затем назначьте владельца:

sudo chown -R admin:admin /var/www/example.org/html

chown меняет владельца и группу. Параметр -R проходит по всему указанному дереву, поэтому точный путь особенно важен. После команды пользователь admin сможет обновлять файлы без запуска редактора от root.

Если ваш пользователь называется иначе, замените оба слова admin. Не используйте переменную или путь, значение которого не проверили, в рекурсивной команде.

Разделите права каталогов и файлов

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

sudo find /var/www/example.org/html -type d -exec chmod 755 {} +
sudo find /var/www/example.org/html -type f -exec chmod 644 {} +

find обходит только указанное дерево. Условие -type d выбирает каталоги, а -type f — обычные файлы. Часть -exec ... {} + передаёт найденные пути программе chmod, которая устанавливает права.

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

Режим 644 не подходит файлам, которые должны оставаться закрытыми. Пароли, закрытые ключи, резервные копии и .env не следует помещать в корень сайта вообще, даже если Nginx настроен не отдавать их по имени.

Проверьте доступ именно от имени Nginx

Администратор с sudo способен прочитать почти любой файл, поэтому обычное открытие от его имени ничего не доказывает. Запустите безопасную проверку как пользователь рабочего процесса Nginx:

sudo -u www-data test -r /var/www/example.org/html/index.html && echo "Nginx может прочитать файл"

sudo -u www-data меняет пользователя только для этой проверки. Команда test -r не выводит содержимое, а лишь проверяет чтение. Текст после && появится только при успехе.

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

После успешного чтения проверьте сам веб-сервер:

sudo nginx -t
curl -I -H 'Host: example.org' http://127.0.0.1/

Первая команда проверяет конфигурацию Nginx и должна завершиться сообщением test is successful. Вторая обращается к Nginx с самого VPS и передаёт имя сайта в заголовке Host. Код 200 или предусмотренное перенаправление подтверждает, что программа выбрала нужный сайт и открыла файл.

Если тест чтения проходит, но Nginx отвечает 404, проверяйте путь в директиве root и выбранный блок server. Если приходит 403, смотрите журнал ошибки Nginx: там обычно указан файл или каталог, доступ к которому запрещён.

Почему не нужно назначать владельцем www-data

Если Nginx только раздаёт статический сайт, право записи ему не даёт полезной функции. Напротив, ошибка в веб-сервере или подключённом приложении сможет изменить страницу, если рабочий процесс владеет файлами.

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

Почему chmod 777 скрывает проблему

Режим 777 разрешает чтение, запись и выполнение владельцу, группе и всем остальным локальным пользователям. После него ошибка доступа часто исчезает, потому что исчезает сама граница между процессами.

Это опасно на сервере с несколькими приложениями. Компрометация одной службы позволит изменить JavaScript или HTML другого сайта. Кроме того, рекурсивный chmod 777 делает исполняемыми обычные изображения и документы, хотя им это право не нужно.

Правильное исправление отвечает на два вопроса: какой пользователь выполняет операцию и какая именно операция ему нужна. Для Nginx со статическим сайтом ответ — www-data должен пройти по публичным каталогам и прочитать готовые файлы.

Когда простой модели недостаточно

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

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

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

Первоисточники

• GNU Coreutils: права доступа к файлам
• GNU Coreutils: числовые режимы
• NGINX: руководство для начинающих