systemd DynamicUser 如何运行无固定账号的服务

很多后台服务并不需要一个长期存在的系统账号：它们只在进程运行期间需要一个低权限身份，停止后既不登录，也不接收邮件，更不需要管理员继续维护密码、主目录和账号清单。对这类服务，DynamicUser=yes 可以把账号生命周期交给 systemd：单元启动时分配临时 UID/GID，停止后释放；账号不会作为固定记录写入 /etc/passwd 或 /etc/group。

但“动态”不等于可以忽略文件所有权。动态 UID 会被复用，如果服务把文件遗留在任意目录，后来拿到同一数字 UID 的另一个服务可能继承访问权。因此，DynamicUser 真正可用的关键不是单独加一行配置，而是同时采用 systemd 的托管目录模型。

官方参考：https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html

先给答案：账号随服务创建和回收

一个实用的判断方式是：如果服务程序只需要读取自身二进制和配置，写入少量运行状态、缓存或日志，而且没有外部系统要求固定数字 UID，那么它通常适合 DynamicUser。最核心的配置如下：

[Service]
# 让 systemd 在服务运行期间分配临时用户和组
DynamicUser=yes

# 名称稳定便于日志和进程查看，但不要求预建 /etc/passwd 记录
User=metric-collector

启动时，systemd 为 metric-collector 解析并分配动态身份；服务停止后，该身份被释放。若机器上已经存在同名静态账号，systemd 会使用现有账号，而不是再创建一个冲突的动态身份。这个细节使同一份单元既能在默认环境中零账号部署，也能在有兼容性要求的环境中由管理员预建静态账号。

账号生命周期为什么能减少运维负担

传统部署通常要求先执行 useradd --system，再处理账号删除、UID 冲突和镜像或主机间的编号一致性。DynamicUser 把这部分状态收回到单元生命周期：PID 1 在启动阶段分配动态 UID/GID，通过 nss-systemd 提供名称解析，随后以该身份启动进程；单元结束后，名称与身份关系不再长期占用本地账号数据库。

systemd 通常从动态系统用户区间 61184–65519 分配 UID/GID。这个区间不是无限的，身份在停止后也可能被别的服务复用。因此，动态用户适合“身份短暂、目录受控”的工作负载，而不是所有固定账号场景的机械替代品。

最小可用单元：服务名稳定，账号不落盘

下面是一份可直接改造的服务单元。示例程序从固定路径启动，配置文件只读；运行数据、持久状态、缓存和日志都由 systemd 创建目录并交给动态用户使用。

[Unit]
# 描述会显示在 systemctl status 输出中
Description=示例指标采集服务
After=network-online.target
Wants=network-online.target

[Service]
# 普通前台进程无需 fork
Type=simple

# 启动时分配临时 UID/GID，停止时释放
DynamicUser=yes

# 使用稳定名称，便于日志、状态和进程列表识别
User=metric-collector

# 二进制与配置应由 root 安装并保持不可写
ExecStart=/usr/local/libexec/metric-collector --config /etc/metric-collector/config.yaml

# 让 systemd 创建并授权四类可写目录
RuntimeDirectory=metric-collector
StateDirectory=metric-collector
CacheDirectory=metric-collector
LogsDirectory=metric-collector

# 异常退出时自动恢复，正常停止不反复拉起
Restart=on-failure
RestartSec=3s

[Install]
# 跟随常规多用户系统启动
WantedBy=multi-user.target

配置后的实际路径分别是 /run/metric-collector、/var/lib/metric-collector、/var/cache/metric-collector 和 /var/log/metric-collector。systemd 还会向进程传入对应环境变量，应用可以优先读取这些变量，减少对发行版目录布局的硬编码。

把可写数据交给 systemd 管理

DynamicUser 会强化文件系统保护，应用不应该再随意向 /usr、/etc、/home 或某个自建路径写文件。最稳妥的做法是先按数据生命周期分类，再选择目录指令：

如果应用已经支持标准输出日志，优先让日志进入 journal，甚至可以省略 LogsDirectory=。只有应用必须自己打开日志文件时，才需要显式声明日志目录。类似地，不能因为“以后可能用到”就把所有目录都创建出来，声明越少，写权限边界越清楚。

最容易踩坑的是 UID 复用

动态 UID 的安全前提是：服务停止后，不应在普通可写位置留下仍由该数字 UID 拥有的私有文件。假设服务 A 得到 UID 61234，并在 /srv/shared/a.db 留下文件；A 停止后，UID 61234 被回收；服务 B 后来得到同一个 UID，就可能被内核视为该文件的新所有者。名称不同并不能改变数字所有权判断。

因此要坚持三条规则：

• 持久数据优先放入 StateDirectory= 声明的目录，不要让服务自行在共享树中创建私有文件。
• 共享文件应使用明确的组权限、ACL 或专用静态身份设计，不能依赖一次运行中偶然获得的 UID。
• 应用必须写入现有外部路径时，先确认该路径是否能改造成托管目录；不能改造时，应认真考虑保留静态系统账号。

上线操作与观察方法

将单元保存为 /etc/systemd/system/metric-collector.service 后，按下面的顺序安装和启动。示例中的检查都是读取 systemd 已加载的属性，不依赖固定账号记录。

# 让 systemd 重新读取新增或修改后的单元文件
sudo systemctl daemon-reload

# 立即启动服务，并加入开机启动目标
sudo systemctl enable --now metric-collector.service

# 查看服务状态、主进程和最近日志摘要
systemctl status metric-collector.service

# 查看 DynamicUser、User 与目录声明是否按预期加载
systemctl show metric-collector.service \
  -p DynamicUser \
  -p User \
  -p RuntimeDirectory \
  -p StateDirectory \
  -p CacheDirectory \
  -p LogsDirectory

# 查看本次运行解析出的用户信息；服务停止后该解析可能消失
getent passwd metric-collector

# 通过主进程 PID 观察实际运行身份
ps -o pid,user,group,cmd -p "$(systemctl show -p MainPID --value metric-collector.service)"

排障时，不要把 getent passwd 查不到理解为服务配置失效：服务未运行时，动态身份本来就可能不存在。更可靠的检查顺序是先看单元是否处于 active，再读 MainPID 与进程身份，最后检查托管目录和日志。

隐含的安全收紧与兼容性代价

启用 DynamicUser 不只是换一个 UID。systemd 会同时收紧多个文件系统和 IPC 行为，其中包括隐含的 ProtectSystem=strict、ProtectHome=read-only，以及不能关闭的 RemoveIPC=。这正是它适合最小权限服务的原因，也解释了为什么某些老程序一开启就报“只读文件系统”或无法访问主目录。

迁移旧服务时，建议先列出全部写入点：配置回写、插件下载、临时文件、Unix 套接字、数据库、缓存、日志和崩溃转储。把每一项归入托管目录或只读路径。如果应用把运行状态写回安装目录，正确做法通常是调整应用参数，而不是放宽整个文件系统保护。

什么时候不要用 DynamicUser

以下场景更适合静态系统账号，或者至少需要额外设计后再使用 DynamicUser：

• 外部存储、NFS、对象代理或跨主机 ACL 必须识别固定数字 UID/GID。
• 多个服务需要长期共享同一组文件，并依赖稳定属主关系。
• 运维平台按固定账号做审计、配额或授权，无法改为按 systemd 单元识别。
• 服务需要登录 shell、主目录或人工交互，这已经超出“短生命周期服务身份”的模型。
• 应用无法把写入点收敛到 systemd 托管目录，也无法通过参数修改路径。

反过来，指标采集器、Webhook 接收器、协议转换器、小型 API、队列消费者和一次性数据处理服务，通常都很适合这种模式：程序本体只读，配置由管理员维护，运行数据位置清晰，身份不需要跨服务生命周期存在。

常见问题

设置 User= 后还算动态用户吗？

算。配合 DynamicUser=yes 时，User=metric-collector 可以提供稳定可读的名称，但不要求预先写入本地账号数据库。如果同名静态账号已存在，则 systemd 会使用它。

服务停止后持久目录会被删除吗？

RuntimeDirectory= 面向临时运行数据，通常随服务停止清理；StateDirectory=、CacheDirectory= 和 LogsDirectory= 面向跨重启数据，不会因为普通停止自动消失。

DynamicUser 能替代容器吗？

不能。它解决的是服务身份和一部分文件系统最小权限问题，不提供完整容器镜像、独立网络栈或资源配额。需要时仍应结合 cgroup 资源控制、网络隔离、capability、seccomp 或容器运行时。

为什么不直接给服务 nobody 用户？

多个服务共用 nobody 会扩大横向访问面：只要文件权限相同，它们可能彼此读取或修改数据。DynamicUser 为每个服务生命周期分配独立身份，再配合独立托管目录，隔离边界更清楚。

DynamicUser 的价值不只是少执行一次 useradd，而是把身份、目录与单元生命周期绑定起来。落地时记住一个简单公式：动态身份 + 只读程序与配置 + systemd 托管可写目录。只要不能满足其中一项，就先检查是否需要静态账号或更明确的共享权限模型。