必须更改工作目录，因为守护进程若停留在用户目录、挂载点或临时目录，会阻碍文件系统卸载、意外创建敏感文件，并引发权限继承隐患；最佳做法是设为根目录/或专用路径如/var/lib/daemon-name，配合umask、降权和描述符关闭等安全措施。
守护进程不应在用户目录、临时目录或挂载点下运行，最佳实践是将其工作目录设为根目录 / 或专用的只读系统路径（如 /var/lib/daemon-name），同时确保该路径权限严格、无写入风险。
为什么必须更改工作目录？
守护进程启动后若仍停留在原工作目录（比如用户家目录或项目目录），可能带来三类风险：
- 阻止文件系统卸载：若工作目录位于可移动设备或网络挂载点，系统无法安全卸载该设备
- 意外创建临时文件：程序崩溃或日志逻辑异常时，可能在非预期位置生成敏感文件或填充磁盘
- 权限继承隐患：当前目录的属主和ACL可能被误用于创建配置或缓存，导致越权访问
推荐的工作目录选择
不同场景对应不同路径策略，核心原则是“最小暴露、固定归属、不可写（除必要）”：
-
/：最通用的选择。调用
chdir("/")是传统守护进程标准步骤，确保不依赖任何挂载点，也避免路径长度或字符问题 -
/var/lib/your-daemon：适合需要持久化状态（如数据库、缓存、PID文件）的服务。该目录应由包管理器或安装脚本提前创建，并设置属主为专用低权限用户（如
daemon:daemon），权限为0750 - /run/your-daemon：仅用于运行时文件（如 socket、pidfile）。该路径是内存文件系统（tmpfs），重启即清空，天然防持久化泄露；需 systemd 或 init 脚本确保启动前已创建并授权
- 避免使用
/tmp、/var/tmp、/home/*：这些路径通常全局可写或受用户控制，不符合最小权限原则
配套安全措施不能少
仅改目录不够，还需同步落实以下操作才能真正保障安全：
- 显式调用
umask(022)或umask(077)，防止守护进程创建的文件被其他用户读取 - 关闭所有继承的文件描述符（特别是 stdin/stdout/stderr），重定向到
/dev/null或专用日志文件，避免泄露控制台信息 - 以非 root 用户身份运行主体逻辑。若启动需特权（如绑定低端口），应在完成初始化后通过
setuid()降权 - 若使用 systemd 管理，应在 service 文件中设置
WorkingDirectory=和NoNewPrivileges=yes，并启用ProtectSystem=strict阻止写入关键路径
常见错误示例与修正
以下行为看似方便，实则埋下隐患：
- ❌ 在
~/myapp/下直接./daemon &启动 —— 进程仍关联终端且工作目录可卸载失败 - ❌ 将 PID 文件写入
/tmp/myapp.pid—— 其他用户可篡改或删除，造成竞态或拒绝服务 - ❌ 日志写入
./logs/app.log（相对路径）—— 实际落点取决于启动位置，易失控 - ✅ 正确做法：启动时执行
chdir("/var/lib/myapp"); open("/var/lib/myapp/pid", O_CREAT|O_WRONLY, 0640)，并由 root 创建好目录及权限
