web-dev-qa-db-fra.com

Accès refusé par la racine

Quand je cours

Sudo systemctl disable avahi-daemon.socket

Je reçois

Failed to execute operation: Access denied

Mais c'est exécuté en tant que root, comment refuser l'accès? (CentOS 7)

centosadministratorsystemctl
12
spraff

Je travaille aussi sur CentOS 7 et j'ai un problème similaire:

# systemctl unmask tmp.mount
Failed to execute operation: Access denied

Le déni concerne SELinux. Cela peut être votre cas si vous utilisez SELinux en mode enforcing:

# getenforce
Enforcing

Dans mon cas, l'erreur systemctl avait produit un refus USER_AVC dans le fichier journal 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=?'

Solution

Cet article indique qu'il est dû à un bogue dans systemd et fournit une solution de contournement:

systemctl daemon-reexec

Solution secondaire

Si ce qui précède n'a pas fonctionné, vous pouvez définir le mode SELinux sur permissive:

setenforce 0

et ça devrait marcher. Cependant, cette deuxième solution a des implications en termes de sécurité.

21
Elouan Keryell-Even

Dans mon cas, je venais de mettre à niveau systemd et toute commande systemctl échouait:

# systemctl daemon-reexec
Failed to reload daemon: Access denied
# systemctl status
Failed to read server status: Access denied

Cependant, selon la page de manuel init, vous pouvez faire la même chose en envoyant SIGTERM au démon qui s'exécute en tant que PID 1, ce qui a fonctionné:

kill -TERM 1

Cela a rechargé le démon, après quoi toutes les commandes systemctl ont recommencé à fonctionner.

2
Malvineous

Aucune solution n'a fonctionné pour moi. Il s'est avéré qu'il manquait un signe = sur l'une des lignes de mon fichier .service. J'ai découvert cela en consultant/var/log/messages et j'ai constaté une erreur plus descriptive. Donc, l'accès refusé était trompeur. Ce n'était pas vraiment un problème de sécurité.

1
Jon