开发者工具 · Chmod 计算器
umask 如何决定新文件和文件夹的默认权限
· 工作原理
chmod UNIX 开发人员工作流程
新文件不从 777 开始；首先敷上面膜。这篇文章展示了确切的按位运算、为什么文件和目录最终不同，以及如何推断 umask 022、027 和 077。
Web 服务器无法读取的文件 — cron 作业将 600 文件写入 nginx 服务的目录中，并且没有人对任何内容运行 chmod
新观察到的文件模式可以在此处解码，即使生成它的进程未知。输入600，计算器显示rw--------：所有者读写，组或其他没有权限。这解释了所提供的结果的位。它没有确定计划作业产生该值的原因或 Web 进程是否可以读取该文件。
文章 501 提供必要的诊断限制。有效模式可能与错误的所有权或父目录上缺少执行位共存。该页面既不接收进程标识也不接收路径信息。它可以将 600 与建议的 640 进行比较，并公开添加的组读取位，但它不能将原始模式归因于 umask、服务、shell 或文件系统。
新权限来自哪里 - 请求的模式（通常是 666 对于文件，777 对于目录）和进程的 umask
请求的创建模式和 umask 是后台输入，而不是计算器控件。没有 umask 字段，也没有创建文件或目录的操作。因此，任何创建模式示例都必须作为外部计算结果到达。一旦提供，计算器可以将结果转换为八进制、符号、矩阵、摘要和简单英语形式，而无需声明该值是如何获得的。
这个更正的范围很重要，因为同步输出看起来比实际情况更权威。输入 640 产生 rw-r----- 并标识所有者 read/write 加上组读取。该页面可以验证该表示。它无法预测登录进程、计划任务、服务、容器或存储系统的默认值，因为这些上下文都不会出现在其输入或实现中。
请求的创建模式和 umask 是此处未实现的后台输入
AND-NOT 算术必须在此计算器之外执行。它的核心接受一个完整的整数并将其分解为命名标志；它没有用于创建掩码的第二个操作数。因此，该页面无法演示掩码公式、将减法与按位运算进行比较，或者在进入其结果模式之前确定外部计算是否正确执行。
它可以检查的是最终的位模式。如果另一个可信源提供 640，则矩阵显示所有者读取和写入、组读取以及无其他权限。更改组读取重建 600，同时更改其他读取重建 644。这些转换验证转换器内部的模式算术，而不将它们呈现为创建掩模计算或有关看不见的过程的证据。
AND-NOT 运算必须在计算器外部执行
计算器可以比较结果文件和目录模式，但它不会创建两者。选择 644 后，常规文件解释描述读取和更改文件；将目标切换到目录会将这些动词更改为列出、修改条目和到达名称。该整数仍为 644。这种对比说明了为什么目标类型很重要，而无需断言哪个创建默认任何程序请求。
单独提供的 755 结果可以用相同的方式检查。它的显示是 rwxr-xr-x，所有类的执行都处于活动状态； 644 是 rw-r--r--，自始至终都没有执行。该页面清楚地揭示了这种差异。它不会从 666、777、022 或任何其他后台输入中派生任何值，因为这些计算未在 CHMOD_SOURCES 中实现。
计算器可以比较结果文件和目录模式，但两者都不创建
对于限制性掩码示例，将计算保持在外部并仅解码规定的结果。如果观察到的常规文件是 640，则计算器呈现 rw-r-----；如果观察到的目录是 750，它会呈现 rwxr-x---。所有者在两者中都保留更广泛的访问权限，组收到的权限范围较小，而其他人则没有任何权限。这些陈述直接来自已完成的模式。
另一个外部提供的对，600 和 700，使相同的审查方法可见，而无需声明其来源。模式 600 仅允许所有者对文件进行读写。模式 700 只允许所有者在目录上读取、写入和执行。转换器可以确认每个类别和位，但它无法根据自己的证据将任一结果与特定的 umask 设置相匹配。
工作示例：解码限制性掩码的外部计算结果
进程获取 umask 的位置是外部存储库证据。该计算器不包含与 shell、调度程序、服务管理器、容器或进程环境的集成。因此，将这些系统之一命名为某种模式的原因将超出页面观察到的范围。从在其他地方收集的可信模式开始，然后仅使用此路径使其所有者、组和其他位清晰可见。
命令预览并不能弥补这一证据差距。它可以引用提供的路径并可选择显示 -R，但它从不打开路径或读取进程设置。同样，目标选择器更改解释语言而不是发现对象类型。一致的转换缩小了权限问题；它没有透露哪个组件选择了该模式或该选择是否是有意的。
进程获取 umask 的位置是外部存储库证据
默认 ACL 和显式创建模式不在此工具之外。其数据模型具有一个所有者类、一个组类、其他所有类和三个特殊位。没有命名的 ACL 条目、ACL 掩码、创建调用或程序参数。因此，计算器无法确定完成模式是来自另一个访问控制层还是来自提供特定请求的应用程序。
仍然可以检查模式，而无需将这些机制折叠在一起。输入观察到的八进制值，确认九个符号位置，并将矩阵与四位汇总进行比较。如果一致，则传统模式已被正确解码。任何有关默认值、ACL 效果或程序行为的声明都需要来自创建者和文件系统的证据，而不是同一整数的另一种解释。
默认 ACL 和显式打开模式不在该工具范围内
更正后的工作流程在其他地方计算，然后在此处检查结果模式。提供完整的八进制或 ls 样式字符串，并让同步字段公开每一位。验证可捕获格式错误的八进制数字和符号位置不正确的字母。它不会验证 umask 表达式、发现创建上下文或预测未来文件或目录将接收的内容。
将结果视为一个诊断层。解码后的 640 或 750 可能会揭示意外的授权或丢失的执行位，而文章 501 则提醒我们分别检查所有权和父目录遍历。在指定原因之前停止。计算器证明提供的值如何映射到权限；它不为有关 shell、服务、容器、ACL 或文件系统默认值的声明提供依据。