Go 临时文件权限为什么不是预期值

Go 的 os.CreateTemp 创建出来的临时文件通常是 0600，也就是文件所有者可读写，其他用户没有权限。这个结果不是随机文件名造成的，也不是因为传入了错误的权限参数：CreateTemp 本身就不提供权限参数，并且文档明确规定创建模式为 0o600（应用 umask 之前）。如果业务只是暂存上传内容、生成中间文件或写入短期凭据，这个默认值通常正是安全预期。

先把“期望权限”拆成两件事：创建 API 的固定语义，以及应用在创建之后是否真的需要共享。默认保留 0600；只有明确需要其他用户或进程读取时，才在创建成功后用 Chmod 调整，并重新读取实际模式确认结果。

官方文档：https://pkg.go.dev/os#CreateTemp

先识别问题现场：到底是哪一种“权限不对”

值班时先不要急着把模式改成 0666。常见现场其实有三种：

• 代码把 CreateTemp 当成 OpenFile，以为可以传入 0644 或 0660。
• 创建成功后用 Stat 看到 -rw-------，认为 Go 忽略了配置。
• 文件本身模式看起来正确，但另一个用户或容器进程仍然打不开，于是把问题误判为临时文件权限。

第三种情况还可能与父目录搜索权限、运行用户、容器挂载点或服务之间的用户组配置有关。本文只处理 CreateTemp 的文件模式语义，不把目录访问控制混成文件模式问题。

快速判断：CreateTemp 为什么总是从 0600 开始

CreateTemp(dir, pattern) 返回一个已经打开的文件句柄。官方实现使用读写、创建和排他创建标志，并以 0600 创建文件；模式是在 umask 影响之前给出的，所以 umask 只能进一步收紧权限，不能把它放宽到 0644。

第一个参数为空字符串时，标准库会使用 os.TempDir() 返回的默认临时目录。第二个参数只是文件名模式：星号会被随机字符串替换，不能把权限写进这个字符串。真正的文件名可以从 f.Name() 取得，临时文件不再需要时由调用方负责删除。

处理步骤：先按默认私有文件写代码

如果临时文件只由当前进程使用，最稳妥的处理是接受默认权限，并把关闭和删除放在同一段生命周期里。这样不用在文件刚创建后再暴露一个放宽权限的时间窗口。

package main

import (
	"fmt"
	"log"
	"os"
)

func createPrivateTemp() error {
	f, err := os.CreateTemp("", "report-*.tmp")
	if err != nil {
		return fmt.Errorf("创建临时文件: %w", err)
	}
	// 创建成功后先登记清理责任，避免中途返回留下敏感临时文件。
	defer func() {
		_ = f.Close()        // 主流程会优先处理显式Close错误。
		_ = os.Remove(f.Name()) // 删除失败应交给日志或清理任务继续处理。
	}()

	if _, err := f.WriteString("temporary content\n"); err != nil {
		return fmt.Errorf("写入临时文件: %w", err)
	}
	// 用Stat读取实际模式，排查时不要猜测创建参数是否生效。
	info, err := f.Stat()
	if err != nil {
		return fmt.Errorf("读取临时文件状态: %w", err)
	}
	fmt.Printf("name=%s mode=%s\n", f.Name(), info.Mode().Perm())

	if err := f.Close(); err != nil {
		return fmt.Errorf("关闭临时文件: %w", err)
	}
	return nil
}

func main() {
	if err := createPrivateTemp(); err != nil {
		log.Fatal(err)
	}
}

这里的 Stat 用来读取实际结果，预期的权限位是 0600 或更严格。示例把清理放进 defer，并在主流程中显式关闭；真实项目还可以把删除失败写入结构化日志或交给定时清理任务。

另一个进程必须读取时，创建后再调整

只有当临时文件确实要交给同组进程、辅助程序或其他受控消费者时，才考虑创建后调用 Chmod。重要边界是：文件已经以 0600 创建并打开，随后才会变成目标模式；在这段时间里，其他进程可能无法读取，而调整完成后又会扩大可访问范围。

package main

import (
	"fmt"
	"os"
)

func createGroupReadableTemp() (name string, err error) {
	f, err := os.CreateTemp("", "shared-*.tmp")
	if err != nil {
		return "", fmt.Errorf("创建共享临时文件: %w", err)
	}
	name = f.Name()
	// 出错路径统一关闭并删除，避免留下半成品或错误权限的文件。
	cleanup := func() {
		_ = f.Close()
		_ = os.Remove(name)
	}

	// 只有明确的受控共享需求才放宽到0640；CreateTemp本身不会接受这个参数。
	if err := f.Chmod(0640); err != nil {
		cleanup()
		return "", fmt.Errorf("调整临时文件权限: %w", err)
	}
	info, err := f.Stat()
	if err != nil {
		cleanup()
		return "", fmt.Errorf("确认临时文件权限: %w", err)
	}
	if got := info.Mode().Perm(); got != 0640 {
		cleanup()
		return "", fmt.Errorf("权限未达到要求: got %04o want %04o", got, 0640)
	}
	if err := f.Close(); err != nil {
		_ = os.Remove(name)
		return "", fmt.Errorf("关闭临时文件: %w", err)
	}
	return name, nil
}

0640 只是示例，是否允许同组读取应由部署账户、目录权限和数据敏感级别共同决定。不要因为某个旧接口习惯使用 0666，就把包含令牌、个人数据或导出文件的临时文件无条件放宽。

回滚路径：调整失败或共享不再需要怎么办

如果 Chmod、Stat 或写入失败，回滚目标不是“再试一次更宽的权限”，而是把句柄关闭并删除临时文件。只有当外部接口已经拿到文件名并需要异步处理时，才应把文件交给明确的清理机制；否则失败路径留下的文件会造成数据残留和磁盘堆积。

如果文件已经被交给另一个进程，不能只在当前进程里删除引用就假定共享结束。应先让消费者完成读取，再撤销访问或删除文件；在 Unix 系统上，已打开的文件即使被删除，消费者仍可能继续读取已打开的句柄，这更需要明确生命周期，而不是把删除当成权限撤销。

告警确认：文件模式正确却仍然打不开

可以按下面顺序缩小范围：

1. 记录创建进程的用户、文件绝对路径和 Stat().Mode().Perm()，不要只记录文件名。
2. 确认运行平台。Unix 权限位与 Windows 的只读属性语义不同，不能把一个平台的字符串模式直接当作另一个平台的访问结论。
3. 确认父目录是否允许目标进程穿越和查找；文件有读权限不代表目录一定可访问。
4. 确认目标进程的用户、组和容器挂载是否与创建方一致。
5. 若业务需要共享，重新检查数据是否适合共享，以及是否可以改成管道、Unix socket 或明确的应用层传输。

这组检查能避免一个常见误区：把“另一个用户读不到”简单归咎于 CreateTemp 没有按预期使用 0660。它的默认职责是安全地创建当前进程可用的临时文件，而不是替应用设计跨进程共享协议。

复盘清单：下次看到权限异常先问什么

常见问题

能不能像 OpenFile 一样直接传 0644？

不能。CreateTemp 没有权限参数，默认创建模式就是 0600。需要不同模式时只能创建成功后再按业务约束调整。

umask 能让 CreateTemp 变成 0666 吗？

不能。umask 用来屏蔽权限位，只会让结果更严格；它不会把 0600 放宽成对组用户或其他用户可读。

临时目录权限和临时文件权限是一回事吗？

不是。文件模式控制文件本身，目录模式影响查找、穿越和创建。CreateTemp 的文件模式结论不能替代对父目录和运行用户的检查。

为什么调整到 0640 后仍然不能读？

还要检查目标用户是否属于文件组、父目录是否可访问、容器挂载是否一致，以及平台是否支持你使用的权限语义。先记录实际模式和运行身份，再处理共享方案。

因此，Go 临时文件权限“不符合预期”时，第一判断应是：你期待的是标准库默认的私有临时文件，还是一个跨进程共享对象。前者保留 0600 并做好清理；后者明确共享对象、调整时机、失败回滚和验收条件，才不会用一次粗暴的 Chmod 把排障问题变成数据暴露问题。