Linux 新建文件权限为什么不是设置的 777

Linux 新建文件权限不是设置的 777，通常不是系统把权限“改错”了，而是创建请求、进程的 umask 和父目录的 default ACL 一起决定了最终结果。没有 default ACL 时，可以先按 最终权限 = mode & ~umask 计算；例如请求 0777、umask 为 0022，结果就是 0755。如果创建的是普通文件，程序常用的初始 mode 往往是 0666，即使 umask 为零，也不会凭空得到执行位。

先查创建者进程的 umask，再查父目录是否有 default ACL，最后确认程序传入的 mode。不要看到权限不足就直接 chmod 777。

先把 777 拆成 mode、umask 和 default ACL

权限问题的第一个误区，是把 chmod 777、open(O_CREAT, 0777) 和“新文件最终是 777”当成同一件事。前者是对已有对象的修改，后者只是创建时提供的 mode 参数。Linux 的 umask(2) 规定，umask 中对应的权限位会从创建 mode 中被关闭；没有 default ACL 时，计算式就是 mode & ~umask。

例如：

# 这只是位运算示例，不会修改系统权限
mode=0777
umask_value=0022
printf '最终权限：%o\n' "$((mode & ~umask_value))"  # 022 屏蔽组和其他用户的写权限

输出应为 755。但创建普通文件时，程序通常传入 0666，因为文件的可执行位应由后续明确动作授予；同样的 umask 下，0666 & ~0022 = 0644。这也是“我明明设置了 777，文件却没有 x 权限”的常见原因。

按进程、父目录和创建接口定位权限来源

如果交互式 shell 中创建出来是 0644，服务里却是 0600，先不要比较两个用户的 ls -l。umask 属于进程属性：fork 出来的子进程会继承父进程的值，execve 不会自动清掉它。因此 systemd、容器入口脚本、任务调度器和当前 shell 可能各有一份上下文。

第二条命令适合确认当前进程，不能替代对服务进程本身的检查。若服务由独立启动器拉起，应在服务配置或启动入口中确认它的 umask；若目标目录的 getfacl 中出现 default: 条目，就要把 ACL 作为主要线索。Linux 手册明确说明，父目录有 default ACL 时，umask 会被忽略，继承 ACL 决定基础权限，mode 中没有请求的位仍会被关闭。

文件和目录要分开判断，别用同一套结论

目录需要执行位才能进入和访问其下的路径，所以创建目录时请求 0777 很常见；普通文件通常请求 0666，之后是否可执行由程序逻辑决定。可以用一个最小复查目录确认计算是否符合预期：

这里的结果通常接近 644 和 755，但不要把“通常”当成所有程序的保证。程序可以传入更严格的 mode，父目录可以有 default ACL，创建后也可能有独立的 chmod 或安全策略。stat 负责确认最终 mode，getfacl 负责确认 ACL，二者要一起看。

按风险选择修复方式，而不是直接放开到 777

如果只是测试目录需要组用户协作，可以在明确边界后调整组、目录 setgid 或 ACL；如果是敏感配置、上传文件或服务生成的凭证，更应收紧 owner、group 和其他用户权限。把整个目录改成 777 可能让不该写入的人获得覆盖、替换或植入文件的能力，修复了表面症状，却扩大了资产暴露面。

一份实用的复查清单如下：

• 确认目标是文件还是目录，并记录程序实际传入的 mode。
• 分别读取创建者 shell、服务进程和容器入口的 umask。
• 对父目录执行 getfacl -p，寻找 default: 规则。
• 用 stat -c '%a %U:%G %n' 记录最终权限、属主和属组。
• 只对需要共享的范围做 ACL 或组权限调整，完成后重新创建对象验证。

相关问题

为什么 touch 新文件不是 777？

touch 创建普通文件时通常使用 0666 作为基础 mode，再受到 umask 或 default ACL 影响，所以它没有执行位很正常。

临时执行 umask 777 会让文件变成 000 吗？

在没有 default ACL 的常规路径中，0666 & ~0777 会得到 000；但这只影响该进程及其子进程创建的新对象，不会回写已有文件。

为什么当前终端是 0022，服务创建出来却不同？

因为 umask 属于进程上下文。服务可能由不同的启动器、用户、容器入口或父进程启动，需要检查服务自身的状态和配置。