Astra linux systemctl access denied

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failed to list units: Access denied #8326

Failed to list units: Access denied #8326

Comments

Submission type

systemd version the issue has been seen with

Used distribution

In case of bug report: Expected behaviour you didn’t see

systemclt list-units lists the units.

In case of bug report: Unexpected behaviour you saw

The error message Failed to list units: Access denied .

In case of bug report: Steps to reproduce the problem

systemctl status example.service works though, so it’s very confusing. The output of strace is attached.

The text was updated successfully, but these errors were encountered:

keszybz added the needs-reporter-feedback ❓ There’s an unanswered question, the reporter needs to answer label Mar 2, 2018

Please find the non-truncated output attached.

Do you use any kind of weird MAC? selinux, …? Are you sure your dbus policy is in order?

No SELinux is used. I am not user about the D-Bus policy.

recvmsg(3, ], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC>, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 421 

This suggests that there’s something wrong with your dbus policy. Maye you still have the old policy installed, not the one that current systemd drops in?

Is there a way to query D-Bus for more verbose information?

The following files with dbus in the path are installed.

$ sudo bee query systemd-237-0.x86_64 | grep dbus /etc/systemd/system/dbus-org.freedesktop.resolve1.service//../../../lib/systemd/system/systemd-resolved.service /etc/systemd/system/dbus-org.freedesktop.network1.service//../../../lib/systemd/system/systemd-networkd.service /lib/systemd/system/dbus-org.freedesktop.timedate1.service//systemd-timedated.service /lib/systemd/system/dbus-org.freedesktop.machine1.service//systemd-machined.service /lib/systemd/system/dbus-org.freedesktop.login1.service//systemd-logind.service /lib/systemd/system/dbus-org.freedesktop.locale1.service//systemd-localed.service /lib/systemd/system/dbus-org.freedesktop.import1.service//systemd-importd.service /lib/systemd/system/dbus-org.freedesktop.hostname1.service//systemd-hostnamed.service /usr/share/dbus-1 /usr/share/dbus-1/services /usr/share/dbus-1/services/org.freedesktop.systemd1.service//../system-services/org.freedesktop.systemd1.service /usr/share/dbus-1/system-services /usr/share/dbus-1/system-services/org.freedesktop.timedate1.service /usr/share/dbus-1/system-services/org.freedesktop.resolve1.service /usr/share/dbus-1/system-services/org.freedesktop.machine1.service /usr/share/dbus-1/system-services/org.freedesktop.locale1.service /usr/share/dbus-1/system-services/org.freedesktop.import1.service /usr/share/dbus-1/system-services/org.freedesktop.hostname1.service /usr/share/dbus-1/system-services/org.freedesktop.network1.service /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service /usr/share/dbus-1/system-services/org.freedesktop.login1.service /usr/share/dbus-1/system.d /usr/share/dbus-1/system.d/org.freedesktop.timedate1.conf /usr/share/dbus-1/system.d/org.freedesktop.resolve1.conf /usr/share/dbus-1/system.d/org.freedesktop.machine1.conf /usr/share/dbus-1/system.d/org.freedesktop.locale1.conf /usr/share/dbus-1/system.d/org.freedesktop.import1.conf /usr/share/dbus-1/system.d/org.freedesktop.hostname1.conf /usr/share/dbus-1/system.d/org.freedesktop.network1.conf /usr/share/dbus-1/system.d/org.freedesktop.systemd1.conf /usr/share/dbus-1/system.d/org.freedesktop.login1.conf 

But, let’s close this, and I’ll reinstall the system again, as it seems to work on other systems.

Источник

systemd — Failed to enable unit: Access denied

Пытаюсь написать системд юнит, который будет просто запускать баш-скрипт.

[Unit] Description=KB-Layout-Signal-Watcher After=network.target [Service] Type=simple #Restart=always #RestartSec=1 #PIDFile=/tmp/kb-layout-signal-watcher.pid #WorkingDirectory=/tmp/ #User=root #Group=root #OOMScoreAdjust=-1000 #Environment=PATH=/bin/ ExecStart=/bin/bash /home/bvn13/develop/kb-layout-caps-led/scripts/kb-layout-signal-watcher.sh #ExecStop=kill -0 `cat /tmp/kb-layout-signal-watcher.pid` #ExecReload=kill -0 `cat /tmp/kb-layout-signal-watcher.pid` && /bin/bash /home/bvn13/develop/kb-layout-caps-led/scripts/kb-layout-signal-watcher.sh #TimeoutSec=300 #TimeoutStartSec=0 [Install] WantedBy=multi-user.target 

Но он не хочет запускаться

# systemctl enable kb-layout-signal-watcher.service Failed to enable unit: Access denied 

Уже все опции поотключал — не пойму. Что ему надо?

ExecStart=/bin/bash /home/bvn13/develop/kb-layout-caps-led/scripts/kb-layout-signal-watcher.sh

А зачем нужно указывать интерпретатор, если он и так прописывается в первой же строчке скрипта?

Vsevolod-linuxoid ★★★★★ ( 03.05.19 23:54:38 MSK )
Последнее исправление: Vsevolod-linuxoid 03.05.19 23:55:37 MSK (всего исправлений: 1)

у меня когда-то не работало без этого

Может он банально прав на исполнение твоего скрипта не имеет?

lrwxrwxrwx. 1 root root 79 мая 3 21:24 kb-layout-signal-watcher.service -> /home/bvn13/develop/kb-layout-caps-led/daemons/kb-layout-signal-watcher.service 

я ему в ExecStart уже левый скрипт подсунул, пустой — все равно эта ошибка.

Да, если атрибут разрешающий запуск не установлен то даже под рутом скрипт запускаться не будет.

ну так для этого и стоит ExecStart=/bin/bash .

простой пользователь не может управлять системными юнитами

для юзера запускается свой процесс управления юзерскими службами systemd —user

скрипт надо включать через него

мне не нужно от юзера, мне нужно от рута. и включать его пытаюсь от рута

зы. но ты натолкнул меня на мысль. я скопировал файл юнита в /etc/systemd/system и все запустилось. видать, он, действительно, не дает запустить, если файл лежит где-то в хомяке. как победить? мне же в репу гитовую его хочется добавить и держать там

bvn13 ★★★★★ ( 04.05.19 01:56:08 MSK )
Последнее исправление: bvn13 04.05.19 01:58:44 MSK (всего исправлений: 1)

пардон пропустил # в команде.

ситемные файлики должный лежать в системном месте юникс-вей же 🙂

System Unit Search Path /etc/systemd/system.control/* /run/systemd/system.control/* /run/systemd/transient/* /run/systemd/generator.early/* /etc/systemd/system/* /etc/systemd/systemd.attached/* /run/systemd/system/* /run/systemd/systemd.attached/* /run/systemd/generator/* . /lib/systemd/system/* /run/systemd/generator.late/* User Unit Search Path ~/.config/systemd/user.control/* $XDG_RUNTIME_DIR/systemd/user.control/* $XDG_RUNTIME_DIR/systemd/transient/* $XDG_RUNTIME_DIR/systemd/generator.early/* ~/.config/systemd/user/* /etc/systemd/user/* $XDG_RUNTIME_DIR/systemd/user/* /run/systemd/user/* $XDG_RUNTIME_DIR/systemd/generator/* ~/.local/share/systemd/user/* . /usr/lib/systemd/user/* $XDG_RUNTIME_DIR/systemd/generator.late/*

сделай хардлинк в хомяк плюс chmod 666 ??

нет же. у меня на серверах с убунтой 16.04 сами файлы-юниты лежат то в хомяке, то еще где, а линки на них — в /etc/systemd/system. и все работает.

мне удалось автоматически создать линк, но демон не запускается

[root@bvn13-book daemons]# systemctl link /home/bvn13/develop/kb-layout-caps-led/daemons/kb-layout-signal-watcher.service Created symlink /etc/systemd/system/kb-layout-signal-watcher.service → /home/bvn13/develop/kb-layout-caps-led/daemons/kb-layout-signal-watcher.service. [root@bvn13-book daemons]# systemctl enable kb-layout-signal-watcher.service Failed to enable unit: Access denied 

bvn13 ★★★★★ ( 04.05.19 02:25:43 MSK )
Последнее исправление: bvn13 04.05.19 02:26:16 MSK (всего исправлений: 1)

Источник

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

Вы работаете в контейнере, например Docker или LXC или LXD? Вы точно знаете, что находитесь в контейнере или нет?

Нет, VirtualBox — это не контейнер, а виртуальная машина. Они принципиально разные. Скорее всего, вам нужно бежать, journalctl -xe чтобы выяснить, почему это происходит.

Обратите внимание, что это сообщение об ошибке («Не удалось выполнить операцию: доступ запрещен») также может появляться при попытке доступа к несуществующей службе в принудительном режиме. В разрешающем режиме вы получите «Не удалось выполнить операцию: нет такого файла или каталога».

Я также работаю над CentOS 7, и у меня была похожая проблема:

# systemctl unmask tmp.mount Failed to execute operation: Access denied 

Отказ связан с SELinux. Это может быть ваш случай, если вы используете SELinux в 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, и предоставляется обходной путь:

Вторичное решение

Если вышеописанное не сработало, вы можете установить режим SELinux на permissive :

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

Вместо Removed symlink этого я получаю не вывод, а потом systemctl disable avahi-daemon.socket audit.log

systemctl disable avahi-daemon.socket после успеха setenforce 0 без systemctl daemon-reexec (и теперь я понимаю, что unmask это ваша команда, а не моя :-)) Можно ли делать это и setenforce 1 после?

Пожалуйста, не надо 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 

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

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

Источник

systemctl access denied when root

Are you running in a container, like Docker or LXC or LXD? Do you know for sure you are or are not in a container?

No, VirtualBox isn’t a container, it’s a virtual machine. They’re fundamentally different. Most likely you need to run journalctl -xe to figure out why this is happening.

Note that this error message («Failed to execute operation: Access denied») can also occur when trying to access a non-existing service in enforcing mode. In permissive mode, you would get «Failed to execute operation: No such file or directory».

3 Answers 3

I also work on CentOS 7, and had a similar issue:

# systemctl unmask tmp.mount Failed to execute operation: Access denied 

The denial has to do with SELinux. This can be your case if you are running SELinux in enforcing mode:

In my case, the systemctl error had produced an USER_AVC denial in SELinux log file, /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=?' 

Solution

This article states that it is due to a bug in systemd, and provides a work around:

Secondary solution

If the above did not work, you can set SELinux mode to permissive :

and it should work fine. However, this 2nd solution has security implications.

Источник