Quando corro
sudo systemctl disable avahi-daemon.socket
ottengo
Failed to execute operation: Access denied
Ma viene eseguito come root, come si può negare l'accesso? (CentOS 7)
journalctl -xe
per capire perché questo sta accadendo.
Quando corro
sudo systemctl disable avahi-daemon.socket
ottengo
Failed to execute operation: Access denied
Ma viene eseguito come root, come si può negare l'accesso? (CentOS 7)
journalctl -xe
per capire perché questo sta accadendo.
Risposte:
Lavoro anche su CentOS 7 e ho avuto un problema simile:
# systemctl unmask tmp.mount
Failed to execute operation: Access denied
Il rifiuto ha a che fare con SELinux. Questo può essere il tuo caso se esegui SELinux in enforcing
modalità:
# getenforce
Enforcing
Nel mio caso, l' systemctl
errore aveva prodotto un USER_AVC
rifiuto nel file di registro SELinux /var/log/audit/audit.log
:
type=USER_AVC msg=audit(1475497680.859:2656): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { enable } for auid=0 uid=0 gid=0 path="/dev/null" cmdline="systemctl unmask tmp.mount" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:null_device_t:s0 tclass=service exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?'
Questo articolo afferma che è dovuto a un bug in systemd e fornisce una soluzione:
systemctl daemon-reexec
Se quanto sopra non ha funzionato, puoi impostare la modalità SELinux su permissive
:
setenforce 0
e dovrebbe funzionare bene. Tuttavia, questa seconda soluzione ha implicazioni per la sicurezza.
Removed symlink
e successivamente systemctl disable avahi-daemon.socket
fallisce come prima, producendo la stessa riga inaudit.log
setenforce 0
systemctl disable avahi-daemon.socket
ci riesce dopo setenforce 0
senza systemctl daemon-reexec
(e mi rendo conto ora che unmask
è il tuo comando, non il mio :-)) Va bene solo fare questo e setenforce 1
dopo?
setenforce 0
Allora menzionerò nella mia risposta.
setenforce 0
. Questa è una cattiva pratica nell'ambiente di produzione. Si prega di utilizzare systemctl daemon-reexec
invece.
Nel mio caso, mi ero appena aggiornato systemd
e qualsiasi systemctl
comando non andava a buon fine:
# systemctl daemon-reexec
Failed to reload daemon: Access denied
# systemctl status
Failed to read server status: Access denied
Tuttavia, secondo la init
manpage, puoi fare la stessa cosa inviando SIGTERM
al demone in esecuzione come PID 1, che ha funzionato:
kill -TERM 1
Ciò ha ricaricato il demone, dopo di che tutti i systemctl
comandi hanno ripreso a funzionare.
Nessuna soluzione ha funzionato per me. Si è scoperto che mancava un segno = su una delle righe nel mio file .service. Ho scoperto questo guardando / var / log / messaggi e ho visto un errore che era più descrittivo. Quindi l'accesso negato era fuorviante. Non è stato davvero un problema di sicurezza.