Go 文件权限在 umask 影响下为什么变小

我第一次遇到这个问题，是给 os.OpenFile 传了 0o666，结果新文件却显示成 0644。看起来像是 Go 把权限“改小”了，实际并不是：在 Unix-like 系统上，新文件的最终权限还要经过进程的 umask 屏蔽。最常见的计算是 实际权限 = 请求权限 &^ umask，所以 0666 &^ 0022 = 0644。

我为什么传了 0666，拿到的却是 0644

在 Linux、macOS 等 Unix-like 系统上，umask 是进程的文件创建掩码。它不是“从权限数字里减去一个数”，而是把对应的权限位屏蔽掉。比如常见的 0022 会屏蔽组用户和其他用户的写权限：

这里的前提是文件确实被创建，并且没有默认 ACL 等额外规则介入。Go 的文档把 OpenFile 描述为通用打开调用；权限参数的操作系统限制仍然存在，不应把它当成独立于宿主系统的权限承诺。

OpenFile 的 perm 只在新建文件时真正起作用

排查时我第二个容易忽略的点，是把“打开文件”和“创建文件”混在了一起。下面的调用带有 O_CREATE，因此目标不存在时会用 0o666 作为创建权限；但最终结果仍会受 umask 影响：

package main

import (
	"fmt"
	"os"
)

func createLog() error {
	// O_CREATE 让不存在的文件进入创建路径，0o666 是创建前的请求权限。
	f, err := os.OpenFile("app.log", os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0o666)
	if err != nil {
		return err
	}
	defer f.Close() // 释放文件描述符，避免排查时混入句柄泄漏问题。

	info, err := f.Stat()
	if err != nil {
		return err
	}
	fmt.Printf("mode=%s\\n", info.Mode().Perm()) // 这里只观察结果，不修改权限。
	return nil
}

如果 app.log 已经存在，O_TRUNC 只会截断内容，通常不会把它的权限重置为 0o666；这时传入的 perm 基本不参与已有文件的权限决定。也就是说，第一次创建得到 0644，后来把代码改成 0600，重新运行并不会自动把旧文件变成 0600。

需要改变已有文件权限时，要把它当成单独的权限操作，例如明确调用 os.Chmod，并意识到文件在创建到修改之间可能短暂暴露。对敏感文件，更稳妥的策略通常是先以更受限的模式创建，再按业务需要放宽权限。

我用 umask 和默认 ACL 解释“权限变小”的剩余部分

在目标 Unix 环境里，可以先看启动该 Go 进程的 shell 或服务配置中的掩码：

# 查看当前环境的文件创建掩码；输出只是排查线索。
umask

# 用明确的权限位阅读结果，不把 022 当成十进制数字相减。
stat -c '%a %n' app.log 2>/dev/null || stat -f '%Lp %N' app.log

如果公式与实际结果对不上，下一步看默认 ACL、挂载文件系统和容器运行环境。Linux 的文档说明，在没有默认 ACL 时，新建对象的模式通常按 mode & ~umask 得出；存在默认 ACL 时，内核会按 ACL 规则参与计算，不能只用一个八进制公式解释所有结果。

还有一个很实际的边界：umask 是 Unix-like 语义，Windows 不按同一套文件权限位处理。代码如果要跨平台运行，应把权限要求写成业务策略，而不是假设所有系统都会返回同样的 0644 或 0600。

我现在的排查清单

对我来说，最有用的结论是：os.OpenFile 负责表达“我希望新文件具有什么基础模式”，而最终权限是应用、进程环境和操作系统共同决定的结果。官方参考可以直接查看 https://pkg.go.dev/os#OpenFile；Unix 的掩码语义可对照 https://man7.org/linux/man-pages/man2/umask.2.html。

相关问题

为什么普通文件常用 0666，而目录常用 0777？

普通文件通常不需要执行位，因此创建请求常写 0666；目录需要读、写、进入权限，常见请求值是 0777。两者最后都还会受到 umask 或 ACL 影响。

O_TRUNC 会重新应用 perm 吗？

不会把已有文件权限按传入的 perm 重置。它主要影响文件内容长度；如果业务要求同步调整权限，应显式设计权限修改动作。

Go 能直接读取当前 umask 吗？

标准 os 包没有可移植的读取接口。可以从进程启动环境和部署配置排查；不要为了普通业务逻辑随意修改全进程的 umask，因为它会影响同一进程中其他创建动作。