绝不能将敏感参数写死在.service文件中；应使用EnvironmentFile隔离或systemd的LoadCredential机制加载，严格设权并禁用环境继承与PATH劫持。
在 systemd 服务中注入敏感参数（如密码、密钥、API token）时，**绝不能写死在 .service 文件里**——这类配置会被所有能读取 /usr/lib/systemd/system/ 或 /etc/systemd/system/ 的用户看到，且会留存在进程命令行（ps aux 可见），极易泄露。
用 EnvironmentFile 隔离敏感配置
将敏感变量单独存为受限权限的文件，再由服务引用：
- 创建环境文件：
sudo tee /etc/myapp/secrets.env <<EOF<br>DB_PASSWORD=super_secret_123<br>API_KEY=sk_live_abcde<br>EOF
- 严格设权：
sudo chmod 600 /etc/myapp/secrets.env && sudo chown root:myapp /etc/myapp/secrets.env（仅 root 和服务组可读） - 在
.service中引用：EnvironmentFile=/etc/myapp/secrets.env
禁止通过 ExecStart 行内拼接敏感值
以下写法危险，必须避免：
-
ExecStart=/usr/bin/java -Ddb.password=secret ...→ 密码暴露在ps和/proc/PID/cmdline -
ExecStart=/bin/sh -c 'export TOKEN=...; exec myapp'→ 环境变量仍可能被子进程继承并泄漏
正确做法是让应用自身从文件或专用机制（如 HashiCorp Vault Agent、systemd’s LoadCredential=）加载敏感项，而非靠 shell 注入。
优先使用 systemd 的 LoadCredential 机制（v249+）
这是目前最安全的原生方案，敏感数据由内核密钥环托管，不落地、不进进程内存：
- 准备凭证文件：
sudo mkdir -p /etc/systemd/credentials && echo "my-secret-value" | sudo tee /etc/systemd/credentials/db.password - 设权：
sudo chmod 600 /etc/systemd/credentials/db.password - 在 service 中声明：
LoadCredential=db.password:/etc/systemd/credentials/db.password - 应用通过
/run/credentials/myapp.service/db.password读取（该路径仅服务进程可访问）
禁用全局环境污染与 PATH 劫持
即使用了 EnvironmentFile 或 LoadCredential，若服务运行环境本身不干净，仍可能被绕过：
- 显式清空非必要变量：
UnsetEnvironment=LD_PRELOAD,PATH,HOME - 固定 PATH：
Environment=PATH=/usr/bin:/bin（禁用用户可控路径如~/bin） - 禁止继承调用者环境：
InheritEnvironment=（空值表示全部清除）
不复杂但容易忽略。
