Вот учебный подход к делу SELinux:
Узнайте, активен ли SELinux:
$ sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 24
Policy from config file: targeted
Если это так, некоторые сравнительные проверки могут помочь. Например, на сервере установлен DocumentRoot по умолчанию /var/www/html, но мы хотим, чтобы он был где-то еще, например /path/to/document/root.
Если SELinux не активно возится с ресурсом, ls -dZв каталоге будет показано что-то вроде:
$ ls -dZ /path/to/document/root
? /path/to/document/root/
С другой стороны, если применяются контексты SELinux, это ls -dZвыглядит примерно так:
$ ls -dZ /path/to/document/root
drwxrws--x+ cfgadm cfgadmin system_u:object_r:file_t:s0 /path/to/document/root
Если мы сравним с рабочим DocumentRoot, это будет выглядеть примерно так:
$ ls -dZ /var/www/html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html
_rИ _tотносятся к -r( --roleи -t( --type) аргументы chconВот сокращенная страницы человека.:
NAME
chcon - change file security context
SYNOPSIS
chcon [OPTION]... CONTEXT FILE...
chcon [OPTION]... [-u USER] [-r ROLE] [-l RANGE] [-t TYPE] FILE...
chcon [OPTION]... --reference=RFILE FILE...
DESCRIPTION
Change the security context of each FILE to CONTEXT. With --reference,
change the security context of each FILE to that of RFILE.
--reference=RFILE
use RFILE's security context rather than specifying a CONTEXT value
-R, --recursive
operate on files and directories recursively
На первый взгляд может показаться, что следующее работает, но может и не работать.
$ sudo chcon -R -t httpd_sys_content_t /path/to/document/root
Если веб-сервер по-прежнему не видит DocumentRoot, обратите внимание, что контекст имеет значение вплоть до корня:
$ sudo chcon -R -t httpd_sys_content_t /path/to/document
$ sudo chcon -R -t httpd_sys_content_t /path/to
$ sudo chcon -R -t httpd_sys_content_t /path
На этом этапе веб-сервер может видеть каталог.
Да, я научился трудному пути сегодня вечером.
ПРИМЕЧАНИЕ: использование chcon концептуально имеет недостаток в документации RedHat ( 5.6.1. Временные изменения: chcon ), которая гласит:
The chcon command changes the SELinux context for files. However, changes
made with the chcon command do not survive a file system relabel, or the
execution of the restorecon command.
Используйте semanage и restorecon для внесения более постоянных изменений. Краткий пример:
$ sudo semanage fcontext --add -t httpd_sys_content_t -s system_u \
"/path/to/document/root(/.*)?"
$ sudo restorecon -FR /path/to/document/root
Что касается restorecon , обратите внимание, что -F требуется для воздействия на весь контекст (т. Е. На пользователя и тип). Кроме того, -R означает делать изменения рекурсивно. Аргументы -v или -p могут показывать прогресс как многословно, так и кратко. Используйте -FRnv, чтобы увидеть, что произойдет, без внесения каких-либо изменений.
После того, как semanage используется таким образом, можно просмотреть локальные изменения безопасности с помощью команды вроде:
$ sudo semanage export
Результаты экспорта semanage могут быть сохранены и использованы при импорте semanage, чтобы упростить применение набора изменений к различным системам.
ПРИМЕЧАНИЕ. Этот ответ предоставляет базовый контекст типа для сайта. Безопасность может быть гораздо более гранулированной. Например, посмотрите список типов, которые могут применяться к страницам веб-сервера, с помощью команды, например:
$ seinfo -t | grep http
ПРИМЕЧАНИЕ. Такие утилиты, как semanage и seinfo, могут быть не установлены по умолчанию. По крайней мере, в некоторых дистрибутивах требуемые пакеты могут быть названы примерно так:
policycoreutils-python
setools-console
DocumentRoot, что может дать вам некоторое представление о том, что видит веб-сервер. Вы также можете проверить другие каталоги по пути, хотя, если он действительно под ними,/var/www/проблем не должно быть