systemctl-Zugriff verweigert, wenn root

Wenn ich renne

sudo systemctl disable avahi-daemon.socket

Ich bekomme

Failed to execute operation: Access denied

Aber es wird als root ausgeführt. Wie kann der Zugriff verweigert werden? (CentOS 7)

centos administrator systemctl

— spraff
quelle

Laufen Sie in einem Container wie Docker oder LXC oder LXD? Wissen Sie , ob Sie sich in einem Container befinden oder nicht?

— allquixotic

Ich führe eine neue CentOS-Installation in VirtualBox durch. Zählt das als Container?

— Spraff

Nein, VirtualBox ist kein Container, sondern eine virtuelle Maschine. Sie sind grundlegend anders. Höchstwahrscheinlich müssen Sie rennen, journalctl -xeum herauszufinden, warum dies geschieht.

— Allquixotic

Beachten Sie, dass diese Fehlermeldung ("Vorgang konnte nicht ausgeführt werden: Zugriff verweigert") auch auftreten kann, wenn versucht wird, im Erzwingungsmodus auf einen nicht vorhandenen Dienst zuzugreifen. Im zulässigen Modus erhalten Sie die Meldung "Vorgang konnte nicht ausgeführt werden: Keine solche Datei oder kein solches Verzeichnis".

— Danmichaelo

Antworten:

Ich arbeite auch an CentOS 7 und hatte ein ähnliches Problem:

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

Die Ablehnung hat mit SELinux zu tun. Dies kann der Fall sein, wenn Sie SELinux im enforcingModus ausführen :

# getenforce
Enforcing

In meinem Fall hatte der systemctlFehler eine USER_AVCAblehnung in der SELinux-Protokolldatei zur Folge /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=?'

Lösung

Dieser Artikel gibt an, dass es sich um einen Fehler in systemd handelt, und bietet eine Problemumgehung:

systemctl daemon-reexec

Sekundäre Lösung

Wenn dies nicht funktioniert hat, können Sie den SELinux-Modus folgendermaßen einstellen permissive:

setenforce 0

und es sollte gut funktionieren. Diese zweite Lösung hat jedoch Auswirkungen auf die Sicherheit.

— Elouan Keryell-Even
quelle

Ich bekomme keine Ausgabe statt Removed symlinkund danach systemctl disable avahi-daemon.socketnicht wie zuvor, in die gleiche Linie produzierenaudit.log

— spraff

Können Sie versuchen, den Selinux-Erzwingungsmodus zu deaktivieren? setenforce 0

— Elouan Keryell-Even

systemctl disable avahi-daemon.socketGelingt das nachher setenforce 0ohne systemctl daemon-reexec(und mir ist jetzt klar, dass das unmaskdein Befehl ist, nicht meiner :-)) Ist es in Ordnung, dies einfach und setenforce 1nachher zu tun ?

— Spraff

@spraff Ich weiß nicht, ich bin ein SELinux-Neuling ha ha. Imma erwähne dann setenforce 0in meiner Antwort.

— Elouan Keryell-Even

Bitte nicht setenforce 0. Dies ist eine schlechte Praxis in der Produktionsumgebung. Bitte verwenden Sie systemctl daemon-reexecstattdessen.

— Younes

In meinem Fall hatte ich gerade ein Upgrade durchgeführt systemdund ein systemctlBefehl schlug fehl:

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

Der initManpage zufolge können Sie jedoch dasselbe tun, indem Sie SIGTERMan den Daemon senden , der als PID 1 ausgeführt wird. Das hat funktioniert:

kill -TERM 1

Dadurch wurde der Dämon neu geladen, wonach alle systemctlBefehle wieder funktionierten.

— Bösartig
quelle

Vielen Dank. Mein Problem wurde gelöst, nachdem ich eine Archlinux-Distribution nach langer Zeit aktualisiert hatte.

— Bürgi

arbeitete an Ubuntu 18.10 - Danke!

— Roy Shilkrot

Keine der beiden Lösungen hat bei mir funktioniert. Es stellte sich heraus, dass in einer der Zeilen meiner .service-Datei ein fehlendes = Zeichen vorhanden war. Ich entdeckte dies, indem ich / var / log / messages ansah und dort einen Fehler entdeckte, der aussagekräftiger war. Der Zugriff verweigert war also irreführend. Es war kein wirkliches Sicherheitsproblem.

— Jon
quelle

Sie sollten detaillierter beschreiben, wie Sie diese Frage lösen. Sie sprechen beispielsweise von einer ausführlicheren Fehlermeldung, geben jedoch nicht an, wie genau die Fehlermeldung lautete. Ohne diese Informationen wäre dies besser als Kommentar zu verstehen, da diese Antwort ohne diese Informationen unvollständig ist.

— Ramhound

In welcher Protokolldatei wurde die Meldung angezeigt?

— Rogerdpack