Systemctl Zugriff verweigert, wenn root

28363
spraff

Wenn ich renne

sudo systemctl disable avahi-daemon.socket

Ich bekomme

Failed to execute operation: Access denied

Aber es läuft als root. Wie kann der Zugriff verweigert werden? (CentOS 7)

13
Laufen Sie in einem Container wie Docker oder LXC oder LXD? * Wissen Sie * sicher, dass Sie sich in einem Container befinden oder nicht? Horn OK Please vor 7 Jahren 0
Ich führe eine neue CentOS-Installation in VirtualBox aus. Zählt das als Container? spraff vor 7 Jahren 0
Nein, VirtualBox ist kein Container, sondern eine virtuelle Maschine. Sie sind grundlegend anders. Wahrscheinlich müssen Sie `journalctl -xe` ausführen, um herauszufinden, warum dies geschieht. Horn OK Please vor 7 Jahren 0
Beachten Sie, dass diese Fehlermeldung ("Vorgang konnte nicht ausgeführt werden: Zugriff verweigert") auch auftreten, wenn versucht wird, auf einen nicht vorhandenen Dienst im Erzwingungsmodus zuzugreifen. Im permissiven Modus würden Sie "Fehler beim Ausführen der Operation: Keine solche Datei oder ein solches Verzeichnis" erhalten. danmichaelo vor 7 Jahren 0

2 Antworten auf die Frage

18
Elouan Keryell-Even

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 bewirkt /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 besagt, dass es sich um einen Fehler in systemd handelt, und bietet eine Problemumgehung:

systemctl daemon-reexec

Sekundärlösung

Wenn dies nicht funktioniert hat, können Sie den SELinux-Modus auf Folgendes einstellen permissive:

setenforce 0

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

Ich bekomme keine Ausgabe anstelle von "Removed symlink" und danach schlägt "systemctl disable avahi-daemon.socket" wie zuvor fehl und erzeugt dieselbe Zeile in "audit.log" spraff vor 7 Jahren 0
Können Sie versuchen, den Selinux-Erzwingungsmodus zu deaktivieren? "setenforce 0" Elouan Keryell-Even vor 7 Jahren 0
`systemctl disable avahi-daemon.socket` gelingt nach` setenforce 0` ohne `systemctl daemon-reexec` (und mir ist jetzt klar, dass` unmask` Ihr Befehl ist, nicht meins :-)) Ist es in Ordnung, dies zu tun und ` setenforce 1` nach? spraff vor 7 Jahren 0
@spraff Ich weiß es nicht, ich bin ein SELinux-Neuling. Imma erwähne dann "setenforce 0" in meiner Antwort. Elouan Keryell-Even vor 7 Jahren 0
@spraff kannst du `setenforce 1` danach ausführen. das setzt es zur Durchsetzung zurück. Mark Yisri vor 7 Jahren 0
Bitte nicht 'setenforce 0'. Dies ist eine schlechte Praxis in der Produktionsumgebung. Bitte verwenden Sie stattdessen `systemctl daemon-reexec`. Younes vor 6 Jahren 1
`systemctl daemon-reexec` arbeitete an RHEL 7.4. Pancho Jay vor 6 Jahren 0
`systemctl daemon-reexec` hat bei mir nicht funktioniert, ich bin auf fedora 28.` setenforce 0` hat funktioniert. Normalerweise bin ich gegen diese Sicherheitsangriffe, aber ich schwimme aus Frustration in meinem eigenen Haar, weil ich mit Nonsens-Apis wie 'daemon-reexec' und 'setenforce 0' arbeite. Was macht `setenforce 0`? Warum es den Erzwingungsstatus natürlich erlaubt? aaaaaa vor 5 Jahren 0
0
Jon

Keine der Lösungen funktionierte für mich. Es stellte sich heraus, dass in einer der Zeilen in meiner .service-Datei ein = Zeichen fehlte. Ich entdeckte dies beim Durchsuchen von / var / log / messages und sah dort einen Fehler, der aussagekräftiger war. Der verweigerte Zugriff war also irreführend. Es war nicht wirklich ein Sicherheitsproblem.

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 war. Ohne diese Informationen wäre dies besser als Kommentar zu verstehen, da diese Antwort ohne diese Informationen unvollständig ist. Ramhound vor 7 Jahren 3

Verwandte Probleme