当我在目录中应用默认 ACL 时，我看到default:mask或只是mask在以下两种情况下。
方案 1
-bash-4.2$ ls -ld test/
drwxr-x---. 2 test test 4096 Oct 15 19:12 test/
-bash-4.2$ setfacl -d -m u:arif:rwx test/
-bash-4.2$ getfacl --omit-header test
user::rwx
group::r-x
other::---
default:user::rwx
default:user:arif:rwx
default:group::r-x
default:mask::rwx
default:other::---
方案 2
-bash-4.2$ ls -dl dir/
drwxr-x---. 2 test test 4096 Oct 15 18:17 dir/
-bash-4.2$ getfacl dir
# file: dir
# owner: test
# group: test
user::rwx
group::r-x
other::---
-bash-4.2$ setfacl -m user:arif:rwx dir
-bash-4.2$ getfacl --omit-header dir
user::rwx
user:arif:rwx
group::r-x
mask::rwx
other::---
那么mask这里的目的是什么？
什么
这个 3 位 ACL 系统起源于 TRUSIX。其他 ACL 系统，例如 FreeBSD、MacOS、AIX、Illumos 和 Solaris 中的 NFS4 风格的系统，工作方式不同，并且不存在掩码访问控制条目的概念。
顾名思义，掩码是一个掩码，用于屏蔽用户和组的访问控制条目授予的权限。它是任何访问控制条目可能授予的最大权限，除了文件所有者或“其他”条目。它
and的 3 位与这些其他条目的 3 位一起编辑。因此，例如，如果用户被
rw-访问控制条目授予，但掩码是r--，则该用户实际上只有r--访问权限。相反，如果用户仅--x通过访问控制条目授予，则掩码rwx不会授予额外的权限，并且用户只有--x访问权限。父目录上的默认掩码是应用于在其中创建的内容的掩码设置。它是一种继承形式。
为什么
遗憾的是 IEEE 1003.1e 从未成为标准并于 1998 年被撤销。实际上，19 年过去了，它是一个广泛的操作系统——从Linux到FreeBSD到Solaris（以及 NFS4 风格的 ACL）后一种情况）——实际执行。
IEEE 1003.1e 工作草案 #17 读起来很有趣，我推荐它。在附录 B § 23.3 中，工作组提供了详细的 8 页基本原理，说明 POSIX ACL 相对于旧
S_IRWXG组权限标志的工作方式有些复杂。（值得注意的是，TRUSIX 人十年前提供了大致相同的分析。）这涵盖了面具的存在理由，我将在这里仅进行简要介绍。chmod(…,000)。在存在 ACL 的情况下，如果存在掩码并且旧映射到掩码，这只会关闭所有用户和组权限。S_IRWXG如果没有这个，将旧文件权限设置为000不会影响任何非所有者user或group条目，并且令人惊讶的是，其他用户仍然可以访问该对象。暂时将文件的权限位更改为无访问权限，
chmod 000然后再将其更改回来是一种旧的文件锁定机制，在 Unix 获得建议锁定机制之前使用，正如您所见，即使在 21 世纪人们仍在使用。setlock（自 1990 年代后期以来，建议锁定已经很容易从带有便携式知名工具的脚本中使用。）chmod go-rwx并最终只有对象的所有者才能访问该对象。S_IRWXG同样，除非有掩码并且旧的权限映射到它，否则这不起作用；因为否则该chmod命令不会关闭任何非所有者user或group访问控制条目，从而导致所有者和非所有者组以外的用户保留对预期只能由所有者访问的内容的访问权限。再一次——正如你所看到的——这种
chmod命令在12 年后仍然是公认的智慧。理由仍然成立。and与 ACL 一起编辑的替代系统将需要文件权限标志rwxrwxrwx，这会使许多 Unix 应用程序在看到他们认为的世界时抱怨的事情感到困惑 -可写的东西。or与 ACL 一起编辑，则会chmod(…,000)出现前面提到的问题。因此，一个带有掩码的 ACL 系统。
进一步阅读