I contesti ACL e SELinux sono completamente diversi. C'è un buon tutorial qui per CentOS
Per vedere se SELinux è effettivamente ciò che sta bloccando l'accesso sestatus
$ sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 28
Enforcing nella mia uscita dice che SELinux sta attivamente bloccando gli accessi fuori contesto.
Impostare temporaneamente SELinux su permissivo usando # sudo setenforce Permissive
$ sudo setenforce Permissive
[sudo] password for trogdor:
$ sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 28
La modalità permissiva ti avviserà comunque delle violazioni del contesto SELinux ma non le bloccherà. Questo è un buon modo per verificare se SELinux è effettivamente il problema. Se lo era, e ora funziona tutto, riportare SELinux su Enforcing con sudo setenforce Enforcing. (a parte le modifiche a SELinux con setenforce non sopravviverà al riavvio).
Se SELinux è il problema, devi trovare il contesto corretto in cui dovrebbero essere gli script, o forse è una soluzione semplice con un valore booleano.
Se ti trovi nella tua home directory potrebbe essere semplice come impostare un booleano SELinux. Per visualizzare i booleani, c'è una descrizione dei booleani CentOS qui ma noto che il mio esempio user_exec_content di seguito non è elencato lì, uno strumento più conveniente per le descrizioni booleane è il semanage booleano -l
# getsebool -a | grep exec
...
user_exec_content --> off
...
#sudo semanage boolean -l
...
user_exec_content (off , off) Allow user to exec content
...
Il primo off mostra il suo stato corrente, che è attualmente impostato su off; il prossimo off mostra l'impostazione predefinita, il che significa che sarà comunque spento dopo il riavvio o la rietichettatura del file system.
In tal caso, utilizzare #setsebool -P user_exec_content on
il flag -P per rendere permanente la modifica booleana al riavvio
Se si tratta di un problema di contesto, bene, i contesti sono molto più belli con cui lavorare perché sono più intuitivi. Sembra essere prova, errore ed esperienza su ciò che effettivamente fa cosa con i booleani SELinux, per esempio, non ho idea di cosa faccia effettivamente user_exec_content.
Utilizzare il flag -Z con ls per visualizzare il contesto dei file, ad es. ls -alZ.
$ ls -alZ
-rwxrwxr-x. trogdor trogdor unconfined_u:object_r:user_home_t:s0 backup.sh
Qui user_home_t è il contesto per backup.sh. Supponi di avere un'altra directory con i contesti corretti per eseguire gli script, puoi rispecchiare quel contesto nella directory ./scripts usando:
# chcon -R --reference /onethatworks ./scripts
Per ricontrollare la modifica è stata utilizzata ls -alZ ./scripts
restorecon -Rv ./scripts
dovrebbe rietichettare nuovamente il filesystem, rietichettando ricorsivamente tutti i file e le directory nei contesti aggiornati. In questo caso sta solo facendo la directory degli script e il suo contenuto.
Se funziona, le modifiche apportate qui non sopravvivranno al riavvio e puoi utilizzare quanto segue per rendere permanente la modifica.
# semanage fcontext -a -s system_u -t <context_that_worked> "./scripts(/.*)?
Un'altra opzione per la gestione di SELinux è l'installazione in policycoreutils-guimodo da poter accedere a una GUI di configurazione selinux inserendo # system-config-selinux. Filtrando usando 'script' ho scoperto che molti script usano bin_t come contesto. Puoi anche cambiare la modalità di applicazione con essa. I miei script nella mia home directory vengono eseguiti felicemente user_home_tma sospetto che tu sia altrove se stai riscontrando questi problemi.