Kiedy biegnę
sudo systemctl disable avahi-daemon.socket
dostaję
Failed to execute operation: Access denied
Ale działa jako root, jak można odmówić dostępu? (CentOS 7)
journalctl -xeaby dowiedzieć się, dlaczego tak się dzieje.
Kiedy biegnę
sudo systemctl disable avahi-daemon.socket
dostaję
Failed to execute operation: Access denied
Ale działa jako root, jak można odmówić dostępu? (CentOS 7)
journalctl -xeaby dowiedzieć się, dlaczego tak się dzieje.
Odpowiedzi:
Pracuję również na CentOS 7 i miałem podobny problem:
# systemctl unmask tmp.mount
Failed to execute operation: Access denied
Odmowa dotyczy SELinuksa. Może tak być w przypadku, gdy używasz SELinux w enforcingtrybie:
# getenforce
Enforcing
W moim przypadku systemctlbłąd spowodował USER_AVCodmowę w pliku dziennika 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=?'
W tym artykule stwierdzono, że jest to spowodowane błędem w systemie, i przedstawiono obejście:
systemctl daemon-reexec
Jeśli powyższe nie działało, możesz ustawić tryb SELinux na permissive:
setenforce 0
i powinno działać dobrze. To drugie rozwiązanie ma jednak wpływ na bezpieczeństwo.
Removed symlinka potem systemctl disable avahi-daemon.socketzawodzi jak poprzednio, produkując ten sam wiersz inaudit.log
setenforce 0
systemctl disable avahi-daemon.socketpowiedzie się po setenforce 0bez systemctl daemon-reexec(i zdaję sobie sprawę, teraz unmaskto polecenie, nie moja :-)) Czy to jest w porządku, po prostu to zrobić i setenforce 1po?
setenforce 0w mojej odpowiedzi.
setenforce 0. Jest to zła praktyka w środowisku produkcyjnym. Użyj systemctl daemon-reexeczamiast tego.
W moim przypadku właśnie zaktualizowałem systemdi każde systemctlpolecenie nie działa:
# systemctl daemon-reexec
Failed to reload daemon: Access denied
# systemctl status
Failed to read server status: Access denied
Jednak według strony initpodręcznika możesz zrobić to samo, wysyłając SIGTERMdo demona działającego jako PID 1, który działał:
kill -TERM 1
To przeładowało demona, po czym wszystkie systemctlpolecenia znów zaczęły działać.
Żadne z tych rozwiązań nie działało dla mnie. Okazało się, że w jednym z wierszy w moim pliku .service był brakujący znak =. Odkryłem to, szukając / var / log / messages i zobaczyłem tam błąd, który był bardziej opisowy. Odmowa dostępu wprowadzała w błąd. To nie był tak naprawdę problem bezpieczeństwa.