Ecco un approccio tutorial al caso SELinux:
Scopri se SELinux è attivo:
$ sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 24
Policy from config file: targeted
In tal caso, alcuni controlli comparativi potrebbero aiutare. Ad esempio, un server ha un DocumentRoot predefinito in /var/www/html, ma lo vogliamo da qualche altra parte come /path/to/document/root.
Se SELinux non sta attivamente scherzando con la risorsa, ls -dZnella directory mostrerà qualcosa del tipo:
$ ls -dZ /path/to/document/root
? /path/to/document/root/
D'altra parte, se si applicano i contesti SELinux, ls -dZè più simile a:
$ ls -dZ /path/to/document/root
drwxrws--x+ cfgadm cfgadmin system_u:object_r:file_t:s0 /path/to/document/root
Se confrontiamo con un DocumentRoot funzionante, sarebbe simile a:
$ ls -dZ /var/www/html
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html
L' _re _triguardano -r( --rolee -t( --type) argomenti chconEcco un cut-down man page.:
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 prima vista, potrebbe sembrare che ciò che segue funzioni, ma potrebbe non funzionare.
$ sudo chcon -R -t httpd_sys_content_t /path/to/document/root
Se il server Web non riesce ancora a visualizzare DocumentRoot, tieni presente che il contesto è importante fino alla radice:
$ 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
A questo punto, il web server può vedere la directory.
Sì, stasera ho imparato a mie spese.
NOTA: L'uso di chcon ha concettualmente un aspetto negativo per la documentazione di RedHat ( 5.6.1. Modifiche temporanee: chcon ) che afferma:
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.
Usa semanage e restorecon per apportare modifiche permanenti. Un breve esempio:
$ sudo semanage fcontext --add -t httpd_sys_content_t -s system_u \
"/path/to/document/root(/.*)?"
$ sudo restorecon -FR /path/to/document/root
Per quanto riguarda Restorecon , si noti che -F è necessario per influenzare l'intero contesto (utente e tipo). Inoltre, -R significa apportare modifiche in modo ricorsivo. Gli argomenti -v o -p possono mostrare i progressi in modo dettagliato o conciso. Usa -FRnv per vedere cosa succederebbe senza apportare modifiche.
Una volta utilizzata la semanage in questo modo, è possibile visualizzare le modifiche di sicurezza locali con un comando come:
$ sudo semanage export
L'output dell'esportazione di semanage può essere salvato e utilizzato dall'importazione di semanage per semplificare l'applicazione di una serie di modifiche a vari sistemi.
NOTA: questa risposta fornisce un contesto di tipo molto semplice per un sito. La sicurezza può essere molto più granulare. Ad esempio, vedere un elenco di tipi che possono essere applicati alle pagine del server Web con un comando come:
$ seinfo -t | grep http
NOTA: utilità come semanage e seinfo potrebbero non essere installate per impostazione predefinita. Almeno su alcune distribuzioni, i pacchetti richiesti possono essere chiamati in questo modo:
policycoreutils-python
setools-console
DocumentRoot, che potrebbe darti un'idea di ciò che sta vedendo il web server. Potresti anche voler controllare le altre directory lungo il percorso, anche se è davvero sotto/var/www/quelle non dovrebbe essere un problema