登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  linux

systemd ProtectSystem 怎样限制服务写入系统目录

来源:17golang原创

时间:2026-10-21 16:06:38 189浏览 收藏

给 systemd 服务加写入限制,关键不是把某个目录改成只读,而是先确定“程序只读、状态集中写、临时文件单独处理”的边界。通常可以从 ProtectSystem=strict 开始,再用 ReadWritePaths= 或 StateDirectory= 放行少数业务目录;如果直接把整个 /var 加回可写,隔离就失去了意义。

官方文档:https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html

要点速览
  • true 只读化 /usr、/boot、/efi;full 再包含 /etc;strict 进一步把整个文件系统层级设为只读。
  • ReadWritePaths= 是按路径放行,StateDirectory= 是按服务状态职责创建并管理目录。
  • 它依赖文件系统命名空间,不等于绝对防护;超级块只读、后续子挂载和可修改挂载能力都要单独考虑。

先把 ProtectSystem 当成写路径策略

这项参数作用在服务进程看到的文件系统命名空间里。ProtectSystem=true 会让 /usr/、/boot、/efi 只读;full 额外保护 /etc/;strict 则把整个层级设为只读,但 /dev、/proc、/sys 这类 API 文件系统仍有独立边界。三者不是权限位的替换,也不是把进程用户改成低权限用户。

值主要只读范围适合场景
true/usr、/boot、/efi先保护系统程序和引导文件
full上面范围再加 /etc服务不应改系统配置
strict除 API 文件系统外的整个层级网络服务、只读程序、明确 allowlist 的守护进程

用 ReadWritePaths 设计最小可写面

启用 strict 后,服务真正需要写入的目录必须显式列出。假设服务只生成运行时 socket、保存状态和写入专用日志,可以这样组织单元:

[Service]
# 程序和系统目录默认只读,写权限从严格基线开始
ProtectSystem=strict
ProtectHome=read-only

# 只放行本服务的运行时、状态和日志目录
RuntimeDirectory=order-agent
StateDirectory=order-agent
LogsDirectory=order-agent

# 临时目录按需放行,不要把整个 /var 恢复为可写
ReadWritePaths=/run/order-agent /var/lib/order-agent /var/log/order-agent /var/tmp/order-agent

ReadWritePaths= 控制的是命名空间中的挂载可写性;如果底层文件系统的超级块本身以只读方式挂载,它不能把它变回可写。路径中还要避免把一个大父目录放行后,又在文章其他地方假设其子目录仍然受保护。

systemd ProtectSystem strict 与 ReadWritePaths 的系统目录和服务写路径边界结构说明图
图1:结构说明图,查看只读系统域、服务可写域与 API 文件系统之间的静态边界;不是截图或运行证据。

用 StateDirectory 固定状态目录和权限职责

如果写入内容属于服务的持久状态,优先使用 StateDirectory=order-agent,而不是要求启动脚本先执行 mkdir -p /var/lib/order-agent。systemd 会在系统服务的 /var/lib/ 下创建对应目录,并提供 STATE_DIRECTORY 环境变量;它还会把该路径作为服务命名空间中的可用目录。这样状态路径、目录创建和服务用户的属主关系集中在单元配置里。

短生命周期文件使用 RuntimeDirectory= 更合适:它位于 /run/,服务停止后默认清理。缓存、日志和配置则分别考虑 CacheDirectory=、LogsDirectory=、ConfigurationDirectory=。这些目录设置会排除对应路径对 ProtectSystem 的只读影响,但不会替代应用自身的文件锁和数据一致性设计。

systemd StateDirectory、RuntimeDirectory 和 LogsDirectory 与服务进程的状态写入关系说明图
图2:关系说明图,展示服务进程与运行时、状态、日志目录的职责分界;是原创静态说明图,不代表实际执行结果。

错误模型:写失败时先判断是哪一层拦截

服务启动后出现 Permission denied,不要马上把 ProtectSystem 改回 false。先用 systemctl cat order-agent.service 确认最终合并后的单元内容,再检查应用实际写入路径是否落在 STATE_DIRECTORY 或明确的 ReadWritePaths 中。

# 重新加载单元并重启,确保 drop-in 已生效
sudo systemctl daemon-reload
sudo systemctl restart order-agent.service

# 读取启动错误,区分路径错误、权限错误和应用自身错误
sudo journalctl -u order-agent.service -n 80 --no-pager

若路径在 allowlist 内仍失败,继续区分三类情况:文件系统超级块是只读;服务实际访问的是符号链接指向的另一处;或路径是稍后出现的子挂载。官方说明也提醒,命名空间相关限制可能被特权进程或挂载传播削弱,生产环境可再评估 SystemCallFilter=~@mount 和能力边界。

发布前检查清单与适用边界

  • 先列出程序、配置、状态、缓存、日志、socket、临时文件的真实路径,再选择级别。
  • 优先使用 StateDirectory=、RuntimeDirectory= 等职责化目录,最后才补充窄范围的 ReadWritePaths=。
  • 网络服务通常还应评估 ProtectHome=read-only,但非标准 home 路径不在它的保护范围内。
  • 涉及系统更新、修改系统配置或安装挂载的服务,不适合直接套用 strict,应拆分职责或缩小保护范围。

常见问题

ProtectSystem=strict 会让 /tmp 也不能写吗?

如果同时启用了 PrivateTmp=,/tmp 和 /var/tmp 会有单独的可写临时文件系统;否则应为应用准备明确的临时目录并放入 allowlist。

ReadWritePaths 能否覆盖底层只读磁盘?

不能。它只调整服务命名空间中的挂载访问模式,底层超级块仍是只读时,写入仍会失败。

StateDirectory 适合保存用户上传文件吗?

可以作为服务状态根目录,但上传文件仍要有容量、权限、清理和备份策略;该参数只解决目录创建与服务边界,不替代应用层治理。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>