☰

systemd 219 功能行为

tag-icon • tag-icon systemd lxc
systemd 219 功能行为

我们在 CentOS 7 上的 LXC 容器内运行 systemd 版本 219，但在功能方面遇到了问题。与 systemd.exec(5) 手册页相反，systemd 似乎正在降低功能。我有一个 C 程序和一个 shell 脚本，它们有效地“grep '^Cap' /proc/$$/status”（C 程序以编程方式执行此操作），当在 systemd 下运行时，它们都显示功能降低，而不是从 shell 手动运行。

在容器中：

# grep '^Cap' /proc/$$/status
CapInh: 0000000000000000
CapPrm: 0000001fffffffff
CapEff: 0000001fffffffff
CapBnd: 0000001fffffffff
CapAmb: 0000000000000000

以及 systemd 运行的 C 程序和 shell 脚本：

+ grep '^Cap' /proc/26977/status
CapInh:        0000000000000000
CapPrm:        0000001cfd6cffff
CapEff:        0000001cfd6cffff
CapBnd:        0000001cfd6cffff
CapAmb:        0000000000000000

在线文档暗示较新的 systemd 应该能更好地工作，但我找不到任何类似发行说明的内容来谈论这一点。服务文件不包含任何有关功能的内容；我尝试了各种配置，它们要么被拒绝（即使是手册页中的示例，有时在守护程序重新加载期间，有时在启动服务时），删除所有功能，要么不起作用。

目前来说，使用较新的 systemd 太耗费时间和精力，不太实际，因为这是一种保守的部署。

编辑：我相信这是一个“特权”容器，但如果您通过容器中运行的 sshd 登录，您的 shell 会获得相同的减少的功能集，而通过 lxc-attach 进入则会获得完整的功能集。如果 systemd 拥有完整的功能集，我们会非常高兴。

答案1

发现问题：我所需要的功能被（明确地！）放到了由 saltstack 模板化的 LXC 配置文件中。模板中增加了一些 Jinja，现在需要该功能的容器就有了。

能力之间的差异是由我们的“进入容器”宏（模拟我们以前的容器实现的拐杖）指定“--elevated-privileges”引起的。如果没有它，我们将获得与容器内生成的任何守护进程（例如 sshd）相同的降低的能力。

相关内容