Перезагрузил прокси-сервер nginx (только centos7 + nginx, apache на другом), я получил ошибку:
DOMAIN systemd[1]: Starting Session 439 of user root.
-- Subject: Unit session-439.scope has begun start-up
-- Defined-By: systemd
--
-- Unit session-439.scope has begun starting up.
Jun 08 06:30:02 DOMAIN CROND[16408]: (root) CMD (/usr/local/sbin/script.sh)
Jun 08 06:30:02 DOMAIN CROND[16409]: (root) CMD (/usr/local/bin/script.pl >/dev/null)
Jun 08 06:31:31 DOMAIN sshd[16419]: Connection closed by 10.1.1.3 [preauth]
Jun 08 06:33:40 DOMAIN run-parts(/etc/cron.daily)[16439]: finished 0yum-daily.cron
Jun 08 06:33:40 DOMAIN run-parts(/etc/cron.daily)[16441]: starting logrotate
Jun 08 06:33:45 DOMAIN run-parts(/etc/cron.daily)[16505]: finished logrotate
Jun 08 06:33:45 DOMAIN run-parts(/etc/cron.daily)[16507]: starting man-db.cron
Jun 08 06:33:47 DOMAIN run-parts(/etc/cron.daily)[16516]: finished man-db.cron
Jun 08 06:33:47 DOMAIN run-parts(/etc/cron.daily)[16518]: starting update-ocsp
Jun 08 06:33:56 DOMAIN systemd[1]: Stopping nginx - high performance web server...
-- Subject: Unit nginx.service has begun shutting down
-- Defined-By: systemd
-- Unit nginx.service has begun shutting down.
Jun 08 06:33:56 DOMAIN systemd[1]: Starting nginx - high performance web server...
-- Subject: Unit nginx.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit nginx.service has begun starting up.
Jun 08 06:33:56 DOMAIN nginx[16568]: nginx: [emerg] BIO_new_file("/etc/nginx/ssl/client-ocsp.pem") failed (SSL: error:0200100D:system library:fopen:Permission den
Jun 08 06:33:56 DOMAIN nginx[16568]: nginx: configuration file /etc/nginx/nginx.conf test failed
Jun 08 06:33:56 DOMAIN systemd[1]: nginx.service: control process exited, code=exited status=1
Jun 08 06:33:56 DOMAIN systemd[1]: Failed to start nginx - high performance web server.
-- Subject: Unit nginx.service has failed
-- Defined-By: systemd
-- Unit nginx.service has failed.
-- The result is failed.
После restorecon -R -v /etc/nginx/ssl/ и restorecon -R -v /etc/nginx/ssl/*.pem
Nginx запущен, сегодня был обновлен ocsp, который работал годами ранее, после перезапуска nginx у меня была такая же ошибка с отказом в разрешении.
Как это можно решить? Это рабочий сервер, немного боюсь экспериментировать с ним Спасибо
SELinux не ожидает, что сертификаты будут помещены в /etc/nginx каталог, поэтому, если вы поместите их туда, они могут придумать неправильный контекст.
Храните сертификаты в структуре каталогов по умолчанию в /etc/pki/tls. Если вы используете Let's Encrypt и установили certbot пакет, то вы также можете использовать /etc/letsencrypt.
Файлы также могут иметь неправильный контекст, если вы mv их вместо cp. В системах с поддержкой SELinux всегда не забывайте копировать файлы, а затем удалять оригинал, если его нужно удалить, или используйте mv -Z.
Вот общее решение, позволяющее разрешить то, что ранее было запрещено.
(необязательно) Сначала мы отключаем принудительное исполнение, чтобы мы могли делать все сразу, а не запускать повторно и добавлять по одному изменению за раз каждый раз, когда он терпит неудачу:
setenforce 0
Затем мы запускаем nginx, немного его используем, перезапускаем тоже (так что мы регистрируем все, что связано с выключением)
Затем мы проверяем, что мы разрешим:
grep nginx /var/log/audit/audit.log
И если вас устраивает то, что все упомянутое:
grep nginx /var/log/audit/audit.log | audit2allow -M my-nginx-module
Но если вас не устраивает, настройте grep, чтобы он соответствовал чему-то более конкретному, например:
grep -E "name_connect.*nginx|nginx.*someporttype..." /var/log/audit/audit.log
И теперь мы снова включаем принудительное исполнение и повторно тестируем.
setenforce 1
Лично я бы просто выключил SELinux. Доставляет много хлопот и усложняет настройку. Я восхищаюсь разработчиками SELinux, но сейчас это ужасно. : D