Доступ к systemctl запрещен, когда root

Я также работаю над 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

и это должно работать нормально. Однако это второе решение имеет последствия для безопасности.

В моем случае я только что обновил systemd и любой systemctl команда терпела неудачу:

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

Однако в соответствии с init manpage, вы можете сделать то же самое, отправив SIGTERM демону, работающему как PID 1, который работал:

kill -TERM 1

Это перезагрузило демона, после чего все systemctl Команды снова начали работать.

Ни одно из решений не сработало для меня. Оказалось, что в одной из строк в моем файле.service отсутствует знак =. Я обнаружил это, просмотрев /var/log/messages и увидел там ошибку, которая была более наглядной. Таким образом, доступ запрещен вводит в заблуждение. Это не было действительно проблемой безопасности.