脚本结束时安全自毁敏感临时文件必须用mkstemp创建+shred覆盖+unlink三步闭环;目录级清理需先chmod 000再shred -u -r,避免元数据残留。

脚本结束时安全自毁敏感临时文件,不能靠rm收尾,必须用mkstemp创建 + shred覆盖 + unlink三步闭环;若需目录级清理,应先chmod 000再shred -u -r,否则可能残留元数据。
用 mkstemp 创建可安全销毁的临时文件
直接touch /tmp/secret.txt或拼接路径(如/tmp/$USER-key)会引入竞态和权限泄露风险。必须由系统生成唯一路径:
- Shell 中优先用
mktemp:例如tmpfile=$(mktemp),它调用mkstemp(3)并自动设为0600 - Python 中用
tempfile.mkstemp(),返回(fd, path),后续必须os.close(fd)再操作 - 绝对不要在
/tmp里创建目录后chmod 755——umask可能失效,应显式chmod 0700后再写入
退出前必须 shred -u 覆盖再删,不能只 rm
rm只是解除链接,原始数据块仍可恢复。脚本退出前对每个敏感临时文件执行:
-
shred -n 3 -z -u "$tmpfile":3次随机覆写 + 1次零填充 + 删除文件项 - 若
shred报错“Operation not permitted”,说明文件在 tmpfs 或 SSD 上——此时shred无效,改用dd if=/dev/urandom of="$tmpfile" bs=1M count=1 conv=notrunc后rm -f - 避免
shred -u后又调用rm:重复操作会失败且掩盖真实错误
trap EXIT 清理必须覆盖所有退出路径
trap 'cleanup' EXIT看似可靠,但实际有多个失效场景:
Linux 安全审计工具,检查 SSH 配置、开放/监听端口、防火墙规则(ufw/iptables/nftables)、失败登录尝试、sudoers 权限...
- 进程被
kill -9(SIGKILL)时,trap完全不触发 - 脚本中调用
exec替换自身进程(如exec python3 worker.py),原trap丢失 - 子 shell(
( cleanup ))里定义的trap不出现在父 shell
补救方式:在cleanup函数开头加set -e,并在关键步骤后sync确保覆写落盘;同时用at now + 1 minute设兜底清理(需提前atd启用)。
清理临时目录比单文件更危险,必须分两步
若脚本生成整个临时目录(如/tmp/myapp-$$),直接rm -rf会遗留目录项和 inode 元数据:
- 第一步:递归
chmod 000 "$tmpdir",阻止任何其他进程访问或重命名 - 第二步:
shred -u -r "$tmpdir"(-r递归处理内容,-u最终删除目录项) - 注意:
shred -r不保证清空目录本身 inode,如需彻底,最后用dd if=/dev/zero of="/tmp/myapp-$$" bs=1 count=1 conv=notrunc再rmdir
真正安全的自毁不是“删得快”,而是让文件从创建起就不可见、不可读、不可恢复——mkstemp路径不可预测、权限锁死、覆写策略匹配存储介质特性,这三者缺一不可。SSD 和 tmpfs 上的临时文件尤其要警惕shred失效,得换用dd或依赖PrivateTmp=yes服务隔离。

















