☰

Невозможно запустить службу systemd, запущенную от имени непривилегированного пользователя в CentOS 8

tag-icon • tag-icon permissions centos systemd selinux
Невозможно запустить службу systemd, запущенную от имени непривилегированного пользователя в CentOS 8

Возможно, есть какие-то изменения между CentOS 7 и 8 в отношении systemd и selinux, но я пока не знаю, как с этим справиться.

По какой-то причине (совместимость с другими дистрибутивами) мы используем postgresql 9.6 изEnterpriseDB. Установщик отлично работает на CentOS 7.но больше не на CentOS 8. Установщик создает службу systemd, работающую от имени пользователя postgres (uid=1004 в моем случае).

[Service]
Type=forking
TimeoutSec=120

User=postgres
Group=postgres
...

В конце установщика служба запускается с помощью systemctl. Это сейчас не работает на CentOS 8. Когда я делаю systemctl status, я вижу это:

postgresql.service: Failed to execute command: Permission denied

В файловой системе и в отношении прав пользователя все в порядке.

Как только я отключаю SELinux, всё начинает работать!

В CentOS 7 этого не было. Может ли кто-нибудь сказать мне, что я могу сделать сейчас, ПРЕЖДЕ чем вызывать установщик, чтобы его выполнение заработало?

Приложение

Возможно, я нашел настоящую причину проблемы. Я устанавливаю на другой диск, а не в корневую файловую систему. Установщик начинает работать, если я устанавливаю в корневую файловую систему.Как только исполняемый файл, содержащий директиву «ExecStart» из файла службы systemd, оказывается на другом диске, он перестает работать.Как сказать системе разрешить это???

Спасибо большое за просвещение.

решение1

Другой диск как другая часть файловой иерархии?

С SElinux в силе, это заставляет вас понимать selinux и как создавать переводы контекста файла! Попробуйте, что произойдет, если вы измените, например, файл конфигурации ntpd и файлы журнала ntp в другом месте, например: /services/ntpd/ntp.conf и /services/ntpd/ntp.log !

решение2

Наконец-то я нашел решение своей проблемы неделю назад. Раньше в моем вопросе об этом не упоминалось, так как я думал, что это не будет иметь значения.

Я устанавливал на новый и пустой отдельный диск. Не на корневую файловую систему. Я обнаружил, что установка на корневую файловую систему сработала.

Я тогда сделал

restorecon -r /mountpoint-of-new-disk

и после этого все заработало!

Я считаю, что в CentOS 7 этого делать не нужно.

решение3

Вы скопировали иерархию из корня (/) и вниз на текущий смонтированный диск (т.е. смонтированный как /tmp/tmp_mnt)?

Команда restorecon -r сбрасывает контекст файлов... так что ls -Z вам в помощь

Интерес представляет ls -Z для файлов модулей systemd для postgres и двоичного файла postgres.

Вероятно, политика SElinux различается в centos7 и centos8.

Связанный контент