Bug 38281 - altlinux-kmsg-loglevel fails in unprivileged containers
Summary: altlinux-kmsg-loglevel fails in unprivileged containers
Status: NEW
Alias: None
Product: Sisyphus
Classification: Development
Component: systemd (show other bugs)
Version: unstable
Hardware: all Linux
: P5 normal
Assignee: Alexey Shabalin
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-03-26 18:32 MSK by Arseny Maslennikov
Modified: 2020-03-26 18:32 MSK (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Arseny Maslennikov 2020-03-26 18:32:26 MSK 
Юнит переходит в состояние failed в окружениях, в которых его бессмысленно пытаться запускать.

/bin/dmesg -n $LOGLEVEL вызывает klogctl(8, NULL, 3):

# strace -e trace=syslog dmesg -n 3
syslog(8 /* SYSLOG_ACTION_CONSOLE_LEVEL */, NULL, 3 /* LOGLEVEL_ERR */) = -1 EPERM (Operation not permitted)
dmesg: klogctl failed: Operation not permitted
+++ exited with 1 +++

man:klogctl(2) says:

All commands except 3 and 10 require privilege.  In Linux kernels before 2.6.37, command types 3 and 10 are allowed to unprivileged processes; since Linux 2.6.37, these commands are allowed to unprivileged processes only if /proc/sys/kernel/dmesg_restrict has the value 0. Before  Linux  2.6.37, "privileged"  means  that  the  caller  has  the  CAP_SYS_ADMIN  capability. Since Linux 2.6.37, "privileged" means that the caller has either the CAP_SYS_ADMIN capability (now deprecated for this purpose) or the (new) CAP_SYSLOG capability.

В достаточно непривилегированном lxc-контейнере таких капов нет.
Более того, если их выдать, dmesg всё равно работать не будет.

Предлагаю дописать туда в секцию [Unit]:
ConditionCapability=CAP_SYSLOG
ConditionCapability=|CAP_SYS_ADMIN

и, возможно:
ConditionVirtualization=!container

или предотвратить срабатывание сервиса в окружениях без доступа к /bin/dmesg -n $number как-то лучше.