Linux systemd 环境文件权限 怎样处理

EnvironmentFile 读取失败时，我首先确认服务属于系统管理器还是用户管理器，再检查文件与父目录的访问条件。不能因为系统服务配置了 User=app，就认定环境文件必须让 app 用户直接可读；也不能为了让服务启动，把环境文件改成任何人可读。

下面以已有的 env-perm-demo.service 测试服务说明我的处理取舍，文件只放非敏感标记。文中的对照表是采集方案，不是已经测出的结果；我没有在你的机器执行命令、重启服务或制造故障。官方文档入口：https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html。

一、我先记录启动结果，而不是马上递归改权限

对于权限问题，“重启快了多少”不是有效指标。我更关心三个可记录的结果：管理器是否成功读取环境文件、应用是否收到预期的非敏感配置标记、服务是否因其他问题退出。基线还应包含管理器范围、配置版本、文件属主与模式位，以及异常发生时间。

# 示例服务必须替换为已授权测试对象；以下只查询系统管理器
systemctl --version
sudo systemctl show env-perm-demo.service -p User -p EnvironmentFiles -p Result -p ExecMainStatus
# 只查看元数据，不输出环境文件内容
sudo stat -c '%U:%G %a %n' /etc/env-perm-demo/runtime.env
sudo namei -l /etc/env-perm-demo/runtime.env

stat 与 namei 是常见 Linux 工具，发行版未提供 namei 时按本机工具逐层检查即可。ExecMainStatus 只反映主进程退出状态，不是环境文件读取成功的独立证明；启动失败时结合受限范围的服务日志判断。日志也可能包含程序输出，应在获授权环境内阅读并脱敏，不直接贴进工单。

二、读取身份：管理器和应用不是同一个判断对象

系统服务通常由具有特权的系统管理器启动。环境文件由管理器侧在执行进程前读取，读取所见文件系统也不应直接按应用后续的根目录或绑定挂载理解。User= 控制应用进程身份，不是把环境文件读取动作简单交给那个账户。

用户服务则由用户管理器负责。根用户拥有且仅根可读的文件，对普通用户管理器通常不可读。此时给服务命令加 sudo 并不是解决用户服务配置的正确方式；应先决定究竟要部署为系统服务还是用户服务，再按同一范围配置、操作和观察。

如果应用代码还会自己打开这个文件，那是第二次文件访问，需要应用身份的读取权限。我的做法是把“管理器解析文件”和“应用直接读配置”写成两个需求，避免为不存在的第二个需求扩大权限。

三、单文件权限修复，不用一个模式位解释所有拒绝

以系统服务、普通本地文件和可信目录为前提，可以让 root 管理环境文件并限制普通账户访问。下面命令只针对示例专属目录和单个已存在文件，不创建、不覆盖内容，也不递归修改。执行前应保存原属主、模式位及相关ACL，并确认目录不是共享目录或意外符号链接。

# 仅适用于专属于此测试服务、已经确认归属的目录和文件
sudo chown root:root /etc/env-perm-demo
sudo chmod 0700 /etc/env-perm-demo
sudo chown root:root /etc/env-perm-demo/runtime.env
sudo chmod 0600 /etc/env-perm-demo/runtime.env

这组权限是限定场景的选择，不是所有环境文件的统一答案。若多个受信任服务账户需要直接读文件，应独立设计组权限或ACL；若是用户服务，文件应归相应用户管理并按用户目录布局授权，不能继续套用 root:root 0600。

我也会检查路径各层目录的搜索权限、ACL以及SELinux或AppArmor等强制访问控制。模式位看起来正确不代表访问一定获准。遇到强制访问控制拒绝，应定位策略和标签问题，不关闭整个保护机制来换取启动成功。

四、用非敏感标记做对照，别打印全部环境

测试文件可以只有下面一行配置。它不是 shell 脚本，不要写 export，也不要期待命令替换或 shell 变量展开。

# 仅用于识别配置批次，不放密码或令牌
CONFIG_REVISION=perm-demo-v1

在已有服务的专属 drop-in 中配置文件位置，示例文件名可为 /etc/systemd/system/env-perm-demo.service.d/environment.conf。保留原服务的 ExecStart 与 User 设置，不把下面片段当作完整服务单元。

[Service]
# 必需配置不加减号，避免把读取失败当成可忽略状态
EnvironmentFile=/etc/env-perm-demo/runtime.env

文件路径前的减号用于可选文件，不能拿来证明权限已经修复。必需配置不应通过忽略错误启动成另一个配置状态。存在多个环境文件或 drop-in 时还要检查覆盖关系，不要盲目清空其他配置文件列表。

# 修改单元或drop-in后重载定义；仅在测试维护窗口允许时重启
sudo systemctl daemon-reload
sudo systemctl restart env-perm-demo.service
# 查询启动结果，不使用printenv或完整环境转储
sudo systemctl show env-perm-demo.service -p ActiveState -p SubState -p Result -p ExecMainStatus

只修改环境文件内容通常不需要 daemon-reload，但已运行进程不会因此自动得到新环境；要在合适窗口重新启动所需进程。应用若有自己的配置重载协议，应按实际实现处理，不能把 systemctl reload 当成环境自动更新。

表里没有预填“错误降为零”，因为没有实测就不该给结果。对于用户服务，对应命令使用 systemctl --user 并以所属用户执行；不能一半用系统管理器，一半用用户管理器再比较结果。

五、我保留的回退，不是重新放宽到0644

修改前保存专属 drop-in 和文件权限元数据。出现异常时，恢复本次改动前的配置及明确记录的权限；只移除本次新增且确定归属的配置文件，不使用可能删掉其他人的 drop-in 的广泛回退命令。恢复单元定义后重载，再在维护窗口重启和确认应用状态。

如果旧配置本身暴露敏感信息，不能把恢复不安全权限当作长期方案；应停止扩大影响并协调安全的替代路径。文件被原子替换后，新文件的属主、模式位和ACL也需要纳入发布契约，不能以旧文件曾经正确为依据。

六、权限限制不等于秘密传递机制

环境文件改成0600，只限制了文件访问，不会让进入进程环境的内容自动成为安全凭据。对于密码和密钥，我会评估 systemd 的凭据机制及应用如何读取凭据文件，结合本机版本和部署支持能力实施，不直接把令牌塞进环境变量后宣布“已加固”。

为什么User不是root，root专属文件仍可能正常加载？

因为系统服务的环境文件读取与应用降权运行属于不同边界。前提仍是管理器能够访问文件且没有其他策略阻挡，不能据此保证所有路径都可读。

文件可读，为什么程序还是缺变量？

继续检查实际单元、管理器范围、配置拼写、覆盖设置以及应用是否已经重新启动。不要把管理员shell里的变量自动等同于服务环境。

能把环境文件source进shell来测试吗？

不建议把两种解析规则混用，更不应执行来源不可信的内容。测试应遵循管理器解析规则并只观测必要的非敏感状态。

参考：systemd执行环境与环境文件、systemctl管理范围和操作。我的取舍是先确定谁读取，再收窄具体权限，用可记录的状态判断修复，不拿权限放宽代替原因定位。