文件创建权限与 umask 叠加后的结果判断

在 Linux、macOS 等 Unix-like 系统里，Go 创建新文件时，os.OpenFile 的 perm 不是最终落盘权限。它是交给系统的请求权限，系统还会按当前进程的 umask 关闭对应位。最常用的判断式是：

最终权限 = 请求权限 & ^umask

因此 0666 配合常见的 0022 会得到 0644，0777 配合 0022 会得到 0755。下面把这个结论拆成可复查的输入、计算和观察结果；如果文件已经存在，perm 还不会重新设置它的权限。

先分清请求权限、umask 与最终权限

这里有三个容易被混在一起的量：

所以排查“我明明传了 0666，为什么文件是 0644”时，不能只看 Go 源码里的常量。应同时记录创建动作、进程的 umask 和创建后读取到的模式。os.OpenFile 文档明确把 perm 描述为 “before umask”，而 os.FileMode 的低九位对应 Unix 的 rwxrwxrwx 权限位。

用八进制位运算判断新文件结果

把权限写成三组八进制数字会更直观：第一位是所有者，第二位是组，第三位是其他用户。umask 不是“要加上的权限”，而是“要屏蔽掉的权限”。因此计算时要先按位取反，再与请求值相与。

这个表给的是普通 Unix 创建路径。Linux 的 umask(2) 文档还说明：如果父目录设置了默认 ACL，系统会优先沿 ACL 继承路径计算权限，不能机械地把所有结果都套成单纯的 mode & ^umask。

在 Go 中创建并读取实际权限

Go 代码的职责是把请求值传给系统，并在创建后读取结果。下面的示例故意使用 0666，这样运行时结果会明显受到当前进程 umask 影响；代码中不把某个固定结果写死。

package main

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

func main() {
    const requested = 0o666 // 文件请求可读写，最终结果仍会受 Unix umask 影响。

    file, err := os.OpenFile("permission-demo.txt", os.O_WRONLY|os.O_CREATE|os.O_TRUNC, requested)
    if err != nil {
        log.Fatal(err)
    }

    // 写入失败时先关闭文件，避免把打开的文件描述符留在进程里。
    if _, err := file.WriteString("permission check\n"); err != nil {
        _ = file.Close()
        log.Fatal(err)
    }
    // 显式检查 Close 错误，确保缓冲或底层写入错误不会被遗漏。
    if err := file.Close(); err != nil {
        log.Fatal(err)
    }

    info, err := os.Stat("permission-demo.txt")
    if err != nil {
        log.Fatal(err)
    }
    // Perm() 读取创建后的低九位，不是 OpenFile 传入的请求值。
    fmt.Printf("requested=%#o actual=%#o\n", requested, info.Mode().Perm())
}

如果当前进程的 umask 是 0022，普通 Linux 文件系统路径下，输出的 actual 通常就是 0644。如果启动这个程序的服务管理器、容器入口或父进程使用了 0077，同一份 Go 二进制就可能得到 0600。这不是 Go 运行时随机改权限，而是创建时所在进程环境不同。

分别处理目录、已存在文件和默认 ACL

不要把“创建文件”的结论直接套到所有文件系统操作上，至少要区分三条路径。

1. 新建普通文件：使用 os.OpenFile 搭配 os.O_CREATE 时，perm 才进入创建权限计算，普通 Unix 路径按请求值与 umask 组合。
2. 新建目录：os.Mkdir 和 os.MkdirAll 的权限参数同样是 umask 处理前的值，但目录通常需要执行位才能进入；不能用文件的 0666 经验替代目录模式。
3. 文件已经存在：O_CREATE 只负责“没有时创建”。对象已存在时，传入的 perm 不会把旧权限重置为新值；需要改变已有对象，应明确调用 os.Chmod，并单独处理权限变更失败。

另一个经常造成“公式算对了但结果不同”的因素是父目录默认 ACL。Linux 文档指出，父目录有 default ACL 时，权限位可能按继承的 ACL 计算；此时应检查目录 ACL 与进程环境，而不是继续改 Go 里的 0666。

用对照表和基准记录工程结论

权限问题的基线不是一个抽象的“安全”标签，而是一组可以复查的指标：请求模式、进程 umask、对象是否新建、最终模式，以及父目录是否存在默认 ACL。建议把这些列放进排障记录中，再比较不同启动方式下的差异。

# 记录当前 shell 的 umask；它只描述当前进程环境，不能替代程序内的实际观察。
umask

# 查看创建后的低九位；用数字模式便于和 Go 的 %#o 输出对照。
stat -c '%a %n' permission-demo.txt

# 查看父目录 ACL；如果系统没有 getfacl，可跳过这一项并检查平台文档。
getfacl -p .

在服务、容器和本地 shell 中分别记录一次，通常比反复修改 perm 更快定位差异。若应用确实需要固定权限，先明确它是“创建时的最低请求值”还是“创建完成后的最终策略”：前者使用合适的 perm，后者还要考虑 umask、ACL、服务启动环境，以及是否需要在创建后显式 Chmod。

不要把“稳定得到 0644”当成无条件目标。共享文件、私密凭据、临时文件和日志文件的安全边界不同；更严格的 umask 可能是正确配置，也可能让协作进程无法读取。应以实际访问者和部署环境为准。

结论：先看输入，再看进程环境

判断 Go 文件创建权限时，可以固定按这个顺序：先看 OpenFile 或 Mkdir 传入的请求模式，再确认当前进程的 umask，然后确认对象是否真的新建，最后用 FileInfo.Mode().Perm() 读取实际结果。普通 Unix 路径的核心计算是 requested & ^umask；已存在文件、默认 ACL 和非 Unix 平台则要走各自的边界判断。

相关问题

为什么 Go 传入 0666，文件却是 0644？

因为 0666 是 umask 处理前的请求值。当前进程若使用 0022，普通 Unix 创建路径会关闭组和其他用户的写位，结果就是 0644。

把 OpenFile 的 perm 改成 0644 能绕过 umask 吗？

不能把它理解成绕过。0644 仍是创建请求值，系统还会应用 umask；如果 umask 关闭了更多位，最终结果可能比 0644 更严格。

文件已经存在时，OpenFile 的权限参数会生效吗？

不会。perm主要参与新建对象；已存在文件的权限不会因为再次使用 O_CREATE 而自动重置。需要改已有权限时，应明确调用 os.Chmod。