如何解决systemd服务间kernel keyring共享失败问题？

核心问题分析 #

你遇到的问题本质是：即便设置了User=root和KeyringMode=shared，两个服务默认仍使用各自独立的session keyring，而非共享的全局keyring。KeyringMode=shared仅作用于单个服务内部的进程间共享，无法跨服务打通。

具体解决方案 #

1. 让两个服务共享root的User Keyring #

在服务A和服务B的.service配置文件中，添加以下配置，强制服务使用root的持久化user keyring（而非临时session keyring）：

Keyring=user
KeyringMode=shared
User=root

• Keyring=user：指定服务使用用户级别的持久化keyring（root的user keyring是全局持久的，不会随服务结束销毁）
• KeyringMode=shared：确保服务内部所有进程共享这个keyring

2. 确保密钥被添加到共享的User Keyring #

e4crypt默认可能将密钥存入当前服务的session keyring，需要手动将密钥迁移到user keyring，或者直接在创建时指定目标keyring：

方式1：创建后迁移密钥

在服务A的脚本中，创建密钥后执行以下命令：

# 查找e4crypt创建的密钥ID（@s代表当前session keyring）
KEY_ID=$(keyctl search @s e4crypt)
# 将密钥链接到root的user keyring（@u代表user keyring）
keyctl link "$KEY_ID" @u
# 可选：从session keyring移除密钥，避免冗余
keyctl unlink "$KEY_ID" @s

方式2：创建时直接指定keyring

如果e4crypt支持指定keyring参数（部分版本支持--keyring选项），可以直接在创建密钥时指定：

e4crypt add_key --keyring=@u <你的加密参数>

3. 确保服务启动顺序正确 #

在服务B的.service文件中添加依赖配置，保证服务A完成密钥创建后再启动服务B：

After=serviceA.service
Requires=serviceA.service

• Requires：强制服务A启动失败时，服务B也不会启动
• After：确保服务B在服务A完全启动后再执行

4. 验证配置效果 #

• 在服务A的脚本末尾添加keyctl show @u，确认密钥已存在于root的user keyring
• 在服务B的脚本开头添加keyctl show @u，检查是否能看到相同的密钥条目

额外注意事项 #

• 避免在服务中使用PrivateUsers=yes或其他强隔离配置，这类选项会隔离keyring空间
• 如果需要长期保留密钥（重启后依然存在），可以使用persistent keyring（@p），但需要先通过keyctl persistent @u初始化

内容的提问来源于stack exchange，提问作者synalice