#Признаки блокировки SELinux
Типичные картины: nginx отдаёт 403 на файлы, которые читаются от root; в error.log стоит Permission denied при открытии каталога сайта; при обращении к бэкенду (PHP-FPM, Node) пишет connect() failed (13: Permission denied); не удаётся запуститься на нестандартном порту. Права Unix (chmod, chown) при этом выглядят правильными. SELinux — отдельный уровень контроля: процесс может обращаться только к объектам с разрешённым типом контекста.
#Типичные причины
| Возможная причина | Как узнать | Что делать |
|---|---|---|
Файлы скопированы из домашнего каталогаСохранили контекст user_home_t. | ls -Z показывает не httpd-тип. | В AVC определите реальный путь сайта. Для стандартного расположения проверьте ls -Z и при необходимости restorecon; не применяйте шаблон /srv/site буквально. |
Нестандартный каталог сайтаСайт в /srv или /data. | После restorecon контекст неправильный. | Для нестандартного DocumentRoot добавьте точное правило semanage fcontext и примените restorecon только к выбранному каталогу. |
| Сокет PHP-FPM или проксиnginx не может подключиться. | В журнале отказ name_connect. | Для соединения с upstream-процессом выясните, что блокирует SELinux: сокет PHP-FPM, TCP или обычные права Unix. Включайте только соответствующий допустимый boolean. |
| Нестандартный портnginx не может занять порт. | Ошибка bind. | Проверьте конкретный порт и его тип в semanage port -l; не открывайте любой порт веб-сервера без подтверждённого AVC. |
| Запись в каталогЗагрузки, кэш. | Отказ на запись при верных правах. | Присваивайте метку записи httpd_sys_rw_content_t только нужному каталогу загрузок/кэша после анализа прав, не всему DocumentRoot. |
| Права UnixНет права на каталоги выше. | SELinux ни при чём. | Проверьте доступ пользователя Nginx к каталогу и всем родителям через namei -l, исправляйте лишь необходимую часть пути вместо chmod -R 777. |
#Быстрая проверка
- Узнайте режимНа сервере AlmaLinux в терминале выполните
getenforce:Enforcingозначает принудительное применение политики SELinux,Permissive— только регистрацию отказов,Disabled— полное отключение. Затем воспроизведите ошибку веб-сервера и посмотритеsudo ausearch -m AVC,USER_AVC -ts recent. Сам по себе режим Enforcing не является неисправностью; нужно выяснить конкретный отказ и контекст файла или порта. - Временно переключите в PermissiveПеревод SELinux в Permissive допустим только как краткая контролируемая проверка администратора в безопасном окне обслуживания, если журнал AVC не дал ответа. Прежде чем менять режим, запишите исходный
getenforceи сохраните доступ к консоли. Если политика организации запрещает ослабление защиты, этот шаг пропустите. После теста сразу верните Enforcing и исправьте конкретный контекст/boolean; не оставляйте сервер без защиты. - Верните EnforcingЕсли администратор временно перевёл SELinux в Permissive только для диагностики, сразу после сбора журнала верните исходный защищённый режим командой
sudo setenforce 1из терминала AlmaLinux. Проверьтеgetenforce: должно бытьEnforcing. Команда меняет текущий режим до перезагрузки, но не заменяет исправление неверного контекста файла или политики; не оставляйте SELinux отключённым как «решение» ошибки Nginx. - Найдите отказВ терминале выполните
sudo ausearch -m AVC,USER_AVC -ts recentсразу после воспроизведения ошибки nginx. Найдите запрещённое действие (denied), имя процесса, путь и тип контекста (tcontext). Еслиausearchотсутствует, проверьте пакетauditи журнал черезjournalctl. Сверьте отказ с конфигурацией nginx и правами UNIX, прежде чем менять контекст или SELinux boolean. - Получите подсказкуЕсли установлен
setroubleshoot-server, командаsudo sealert -a /var/log/audit/audit.logможет дать объяснение обнаруженных отказов. Сравните её предложение с назначением каталога и процессом nginx, не копируйте автоматически командыaudit2allow: они могут разрешить избыточные действия. Если журнал пуст, проверьте, что ошибка возникла в проверяемый период, и посмотрите сообщения nginx. - Исправьте контекст или булеву переменнуюВ Linux откройте «Терминал» (в большинстве настольных сред Ctrl+Alt+T); на удалённом сервере войдите по SSH только при наличии прав администратора и запасного доступа. Сначала выполните команды диагностики в блоке ниже и проверьте вывод. Перед командами, изменяющими загрузчик, сеть или файлы, сохраните копию данных и убедитесь, что выбран нужный диск/раздел.
- Верните и подтвердите защиту SELinuxПосле диагностики обязательно выполните
getenforce; если режим временно был Permissive, согласованно верните Enforcing, затем повторите запрос к проблемному ресурсу. Сохраните новую AVC-запись и проверьте доступ только к нужному пути. Постоянное отключение SELinux, глобальное разрешение записи иchmod -R 777недопустимы. - Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
Если semanage не найдена, установите пакет: sudo dnf install policycoreutils-python-utils.
Linux · Терминал (Bash)КомандаНужен sudo
Не выдавайте право записи веб-серверу на весь каталог условного сайта. Назначение контекста возможно только для конкретного реального пути после выяснения потребности записи.
sudo ausearch -m AVC -ts recentLinux · Терминал (Bash)Команда
Показ состояния разрешения. Включение глобального сетевого доступа к сервисам изменяет политику SELinux и не является универсальным исправлением.
getsebool httpd_can_network_connectLinux · Терминал (Bash)КомандаНужен sudo
Только просмотр зарегистрированных веб-портов. Используйте реальные порт и протокол при подтверждённом отказе SELinux.
sudo semanage port -l | grep http_port_tПосле исправления сделайте sudo systemctl reload nginx и проверьте журнал ошибок sudo tail -f /var/log/nginx/error.log. Если подсказка sealert предлагает создать модуль политики через audit2allow, сначала прочитайте, что именно он разрешает, и применяйте только осознанно.