Настройка прав и SELinux

Половина «неведомых» ошибок Битрикс — это права и SELinux. Разбираем, кто должен владеть файлами, какие режимы ставить каталогам, как работают контексты SELinux в BitrixEnv и как чинить Permission denied, не отключая защиту целиком.

Владелец файлов и группы

В BitrixEnv все файлы сайта принадлежат пользователю и группе bitrix:bitrix. Веб-сервер (Apache) работает от этого же пользователя, поэтому конфликтов «файл создал PHP, а прочитать не может nginx» не возникает. После любой ручной операции — распаковки дистрибутива, копирования, git pull — возвращайте владельца:

chown -R bitrix:bitrix /home/bitrix/www

Режимы доступа chmod

Битрикс рекомендует умеренно строгие права: каталоги — 755, файлы — 644, служебные конфиги с секретами — 600. Массовая установка:

find /home/bitrix/www -type d -exec chmod 755 {} \;
find /home/bitrix/www -type f -exec chmod 644 {} \;

Что такое SELinux и режимы

SELinux — механизм мандатного контроля доступа в RHEL-системах. Он навешивает на файлы и процессы контексты безопасности и разрешает операции только по политике, даже если обычные права это позволяют. Режимы:

• Enforcing — политика применяется, нарушения блокируются;
• Permissive — нарушения только логируются, не блокируются;
• Disabled — SELinux выключен.

Текущий статус смотрят командой sestatus или getenforce. BitrixEnv штатно работает с включённым SELinux и сам расставляет нужные контексты при создании сайтов.

Контексты для веб-каталогов

Чтобы Apache мог читать и писать файлы, каталогам нужен правильный тип контекста. Основные:

• httpd_sys_content_t — только чтение веб-сервером (код, шаблоны);
• httpd_sys_rw_content_t — чтение и запись (/upload, /bitrix/cache, /bitrix/managed_cache, /bitrix/tmp).

Назначение контекста на каталог загрузок:

semanage fcontext -a -t httpd_sys_rw_content_t "/home/bitrix/www/upload(/.*)?"
restorecon -Rv /home/bitrix/www/upload

Булевы политики и сеть

Многое в SELinux управляется булевыми флагами. Для Битрикс важны те, что разрешают исходящие соединения PHP — обмен с 1С, отправка почты, запросы к API:

• httpd_can_network_connect — исходящие сетевые запросы из PHP (curl, sockets);
• httpd_can_network_connect_db — подключение к удалённой БД;
• httpd_can_sendmail — отправка писем.

Включение флага постоянно (с ключом -P):

setsebool -P httpd_can_network_connect on

Список активных флагов веб-сервера: getsebool -a | grep httpd.

Диагностика Permission denied

Если файлы и владелец в порядке, а PHP всё равно ловит Permission denied, почти наверняка виноват SELinux. Алгоритм:

1. смотрим отказы в аудите: ausearch -m avc -ts recent или grep AVC /var/log/audit/audit.log;
2. получаем человекочитаемую подсказку: sealert -a /var/log/audit/audit.log;
3. исправляем контекст через semanage + restorecon или включаем нужный boolean;
4. если политика нетиповая — генерируем модуль: audit2allow -a -M mymodule и загружаем его semodule -i mymodule.pp.

Итог

Права и SELinux — это два уровня одной задачи: файлы должны принадлежать bitrix:bitrix с режимами 755/644 (и 600 для секретов), а SELinux — иметь корректные контексты (httpd_sys_rw_content_t на кеш и upload) и включённые булевы флаги под сетевые операции. Диагностика идёт через audit.log, а не через отключение защиты.

Разбираться в AVC-отказах и политиках под нагруженный прод — работа, где ошибка стоит либо простоя, либо дыры в безопасности. Мы в B2Bsite настраиваем права и SELinux под 1С-Битрикс так, чтобы портал работал без Permission denied и при этом сервер оставался защищённым, и берём администрирование на постоянное сопровождение.