Linux umask 如何影响新文件权限：默认掩码、目录继承与验证方法

排查 Linux 服务新建文件权限时，最容易误判的是把 umask 当成“最终权限”。它其实是一个屏蔽位：程序提出初始 mode，内核再把 umask 指定的权限位清掉，最后才得到文件或目录的实际权限。把这个关系用 open、mkdir 和 stat 跑一遍，权限问题就不再靠猜。

先把 umask 的计算对象分清楚

Linux 系统调用 open 创建普通文件时，调用方通常给出 0666 这样的初始 mode；mkdir 创建目录时通常给出 0777。这两个数字都不是最后看到的权限，内核会根据当前进程的 umask 屏蔽相应位。

以 umask 022 为例，文件的计算可以写成“0666 去掉写权限屏蔽位，得到 0644”，目录则从 0777 得到 0755。这里不是普通减法，按位关系更准确；因此不要把任意 mode 都套进固定的 0644/0755 结论。

在一个干净 Shell 中验证文件和目录

先开一个临时目录，避免把测试文件混进项目。下面的命令只改变当前 Shell 的 umask，不会修改系统全局配置：

tmp_dir=$(mktemp -d)
cd "$tmp_dir"
umask 022
touch report.txt
mkdir report-dir
stat -c '%a %n' report.txt report-dir

常见输出是 644 report.txt 和 755 report-dir。touch 最终仍由创建文件的程序决定初始 mode；如果文件已经存在，它只更新时间，不会因为 umask 自动收紧已有权限。目录则需要保留可进入、可列举的权限，所以使用 0777 初始 mode 时结果与文件不同。

把权限边界放进服务启动配置

对长期运行的服务，建议先确认服务是由哪个用户启动，再在服务的启动上下文中设置 umask。交互式 Shell 里执行 umask 027，只会影响当前 Shell 和它启动的子进程；另一个终端里的服务不会自动跟着变化。

umask 027
printf 'current umask: '
umask
touch private.txt
mkdir private-dir
stat -c '%a %U:%G %n' private.txt private-dir

对常见的 0666 文件和 0777 目录，027 会比 022 更严格地屏蔽同组和其他用户的部分权限。验证时不要只看权限数字，还要看 %U:%G 输出，防止文件权限正确但所属用户错误。

几个容易把 umask 用错的边界

umask 不是 chmod 的替代品

umask 只参与新对象创建阶段。需要修复已有文件时，应明确使用 chmod，并先确认目标范围；直接把 umask 写进脚本，不能追溯修改历史文件。

程序可以主动收紧初始 mode

程序传入的 mode 可能本来就不是 0666 或 0777，还可能在创建后继续调用权限修改逻辑。因此看到 0640 或其他结果时，先检查创建代码和服务启动环境，不要只根据 umask 反推。

不要把八进制数字当十进制读

022、027、0644 和 0755 是权限位的八进制表示。脚本中改写配置时保留前导零，并用 umask、stat 实测，避免配置解析器把数字当普通十进制。

上线前的最小检查清单

部署新服务或调整启动用户后，可以按这个顺序复查：先确认启动用户和工作目录，再打印实际 umask；随后分别创建一个文件和目录，用 stat -c '%a %U:%G %n' 检查权限、属主和属组；最后确认应用是否在创建后自行修改了权限。这样既能验证 umask 生效，也能把权限异常定位到启动环境还是应用逻辑。

相关问答

为什么 umask 022 下文件是 0644 而目录是 0755？

因为普通文件和目录通常使用不同的初始 mode：文件从 0666 出发，目录从 0777 出发，再分别应用同一个屏蔽位。

修改当前终端的 umask 会影响已经运行的服务吗？

不会。umask 是进程属性，已经运行的服务不会读取另一个终端后来设置的值；应在服务自身的启动上下文中配置并重启后验证。

怎么确认文件权限是 umask 造成的？

同时记录创建程序传入的 mode、启动环境里的 umask，并用 stat 查看最终权限；如果程序创建后又调用权限修改逻辑，还要继续检查那一步。

小结

理解 umask 的关键是记住“初始 mode 加上屏蔽规则，才得到最终权限”。把 open、mkdir、stat 和实际启动用户放在同一条验证链上，既能解释 022 与 027 的差异，也能避免把已有文件、程序二次修改和 Shell 局部设置混为一谈。