Aquí hay un enfoque tutorial para el caso de SELinux:
Averigüe si SELinux está activo:
$ sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 24
Policy from config file: targeted
Si es así, algunas comprobaciones comparativas podrían ayudar. Por ejemplo, un servidor tiene un DocumentRoot predeterminado en /var/www/html, pero lo queremos en otro lugar como /path/to/document/root.
Si SELinux no está jugando activamente con el recurso, ls -dZen el directorio se mostrará algo como:
$ ls -dZ /path/to/document/root
? /path/to/document/root/
Por otro lado, si se aplican los contextos SELinux, se ls -dZparece más a:
$ ls -dZ /path/to/document/root
drwxrws--x+ cfgadm cfgadmin system_u:object_r:file_t:s0 /path/to/document/root
Si lo comparamos con un DocumentRoot en funcionamiento, se vería algo así:
$ ls -dZ /var/www/html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html
El _ry se _trelacionan con -r( --roley -t( --type) argumentos parachcon . Aquí hay una página de manual reducida:
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
A primera vista, lo siguiente puede parecer que funciona, pero puede que no.
$ sudo chcon -R -t httpd_sys_content_t /path/to/document/root
Si el servidor web todavía no puede ver DocumentRoot, tenga en cuenta que el contexto es importante desde la raíz:
$ 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
En este punto, el servidor web puede ver el directorio.
Sí, aprendí por las malas esta noche.
NOTA: El uso conceptual de chcon tiene una desventaja según la documentación de RedHat ( 5.6.1. Cambios temporales: chcon ) que establece:
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.
Use semanage y restorecon para hacer cambios más permanentes. Un breve ejemplo:
$ sudo semanage fcontext --add -t httpd_sys_content_t -s system_u \
"/path/to/document/root(/.*)?"
$ sudo restorecon -FR /path/to/document/root
Con respecto a restorecon , tenga en cuenta que -F es necesario para afectar todo el contexto (es decir, usuario y tipo). Además, -R significa hacer cambios de forma recursiva. Los argumentos -v o -p pueden mostrar el progreso de manera detallada o concisa. Utilice -FRnv para ver qué sucedería sin hacer ningún cambio.
Una vez que se utiliza semanage de esta manera, es posible ver los cambios de seguridad local con un comando como:
$ sudo semanage export
El resultado de la exportación de semanage se puede guardar y utilizar mediante la importación de semanage para facilitar la aplicación de un conjunto de cambios a varios sistemas.
NOTA: Esta respuesta proporciona un contexto de tipo más básico para un sitio. La seguridad puede ser mucho más granular. Por ejemplo, vea una lista de tipos que se pueden aplicar a las páginas del servidor web con un comando como:
$ seinfo -t | grep http
NOTA: Las utilidades como semanage y seinfo pueden no estar instaladas por defecto. Al menos en algunas distribuciones, los paquetes requeridos pueden llamarse así:
policycoreutils-python
setools-console
DocumentRoot, que podría darle una idea de lo que está viendo el servidor web. También es posible que desee verificar los otros directorios a lo largo de la ruta, aunque si realmente está debajo de/var/www/ellos no debería ser un problema