Когда я бегу
sudo systemctl disable avahi-daemon.socket
я получил
Failed to execute operation: Access denied
Но он запускается с правами root, как запретить доступ? (CentOS 7)
journalctl -xeчтобы выяснить, почему это происходит.
Когда я бегу
sudo systemctl disable avahi-daemon.socket
я получил
Failed to execute operation: Access denied
Но он запускается с правами root, как запретить доступ? (CentOS 7)
journalctl -xeчтобы выяснить, почему это происходит.
Ответы:
Я также работаю над CentOS 7, и у меня была похожая проблема:
# systemctl unmask tmp.mount
Failed to execute operation: Access denied
Отказ связан с SELinux. Это может быть ваш случай, если вы используете SELinux в enforcingрежиме:
# getenforce
Enforcing
В моем случае systemctlошибка привела к USER_AVCотказу в файле журнала 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=?'
В этой статье говорится, что это происходит из-за ошибки в systemd, и предоставляется обходной путь:
systemctl daemon-reexec
Если вышеописанное не сработало, вы можете установить режим SELinux на permissive:
setenforce 0
и это должно работать нормально. Однако это второе решение имеет последствия для безопасности.
Removed symlinkэтого я получаю не вывод, а потом systemctl disable avahi-daemon.socketaudit.log
setenforce 0
systemctl disable avahi-daemon.socketпосле успеха setenforce 0без systemctl daemon-reexec(и теперь я понимаю, что unmaskэто ваша команда, а не моя :-)) Можно ли делать это и setenforce 1после?
setenforce 0в моем ответе тогда.
setenforce 0. Это плохая практика в производственной среде. Пожалуйста, используйте systemctl daemon-reexecвместо этого.
В моем случае я только что обновился, systemdи любая systemctlкоманда не работала:
# systemctl daemon-reexec
Failed to reload daemon: Access denied
# systemctl status
Failed to read server status: Access denied
Однако, в соответствии с initman-страницей, вы можете сделать то же самое, отправив SIGTERMдемону, работающему как PID 1, который сработал:
kill -TERM 1
Это перезагрузило демон, после чего все systemctlкоманды снова начали работать.
Ни одно из решений не сработало для меня. Оказалось, что в одной из строк в моем файле .service отсутствует знак =. Я обнаружил это, просмотрев / var / log / messages и увидел там ошибку, которая была более наглядной. Таким образом, доступ запрещен вводит в заблуждение. Это была не проблема безопасности.