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 -xe
aby 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 -xe
aby 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 enforcing
trybie:
# getenforce
Enforcing
W moim przypadku systemctl
błąd spowodował USER_AVC
odmowę 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 symlink
a potem systemctl disable avahi-daemon.socket
zawodzi jak poprzednio, produkując ten sam wiersz inaudit.log
setenforce 0
systemctl disable avahi-daemon.socket
powiedzie się po setenforce 0
bez systemctl daemon-reexec
(i zdaję sobie sprawę, teraz unmask
to polecenie, nie moja :-)) Czy to jest w porządku, po prostu to zrobić i setenforce 1
po?
setenforce 0
w mojej odpowiedzi.
setenforce 0
. Jest to zła praktyka w środowisku produkcyjnym. Użyj systemctl daemon-reexec
zamiast tego.
W moim przypadku właśnie zaktualizowałem systemd
i każde systemctl
polecenie 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 init
podręcznika możesz zrobić to samo, wysyłając SIGTERM
do demona działającego jako PID 1, który działał:
kill -TERM 1
To przeładowało demona, po czym wszystkie systemctl
polecenia 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.