问题如下。
假设在 CentOS 中，有一个目录“/project”，由组“IT”拥有。用户“peter”和“stewie”都属于组“IT”。
如果系统管理员想对这个目录“/project”设置权限，以支持“stewie 不能删除 peter 创建的文件”的功能，应该设置哪个命令或文件权限？
粘滞位是正确的答案，但是粘滞位的定义是：
当设置目录的粘滞位时，文件系统会以特殊方式处理此类目录中的文件，因此只有文件所有者、目录所有者或根用户可以重命名或删除该文件。
目录所有者是这里的重点。
既然这两个用户都属于拥有“/projects”目录的“IT”组，那么为什么粘性位在这里仍然有效？事实上，Peter 无法删除 Stewie 制作的任何文件，反之亦然，尽管他们都属于拥有该目录的组。这是定义错误还是我的误解？
答案1
相关 POSIX 定义：
文件的属性，指示与进程的用户标识相关的进程的访问权限。如果进程的有效用户 ID 与文件的用户 ID 匹配，则该进程属于文件的文件所有者类。
文件的属性，指示与进程的组标识相关的进程的访问权限。如果进程不在文件所有者类中，并且进程的有效组 ID 或其中一个补充组 ID 与与文件关联的组 ID 匹配，则该进程属于文件的文件组类。[…]
请注意，类别名为“文件所有者”和“文件组”。后者中没有“所有者”。当您看到“文件所有者”（或“文件的所有者”，就像您引用的定义一样）时，它都是关于用户，并注意组。
另一个 POSIX 定义证实了这种解释：
有关文件的信息，用于与其他信息一起确定进程是否具有对文件的读取、写入或执行/搜索权限。这些位分为三部分：所有者、群组和其他。每个部分都与相应的文件类进程一起使用。这些位包含在文件模式中。
[…]
[重点是我的]
它说“所有者、群组和其他人”，而我们可以非正式地说“用户、群组和其他人”。
那些说“文件所有者...你的意思是拥有该文件的用户？还是组？'的人并不完全符合 POSIX 标准。
粘性位的定义使用术语“文件所有者”，而不使用术语“文件组”（或“文件组”）。这意味着它与组无关，组与粘性位的工作方式无关。
你的问题的答案
为什么粘滞位在这里仍然有效？
是：因为它没有考虑群体根本。
这是定义错误还是我的误解？
该定义与此行为一致，因为它引用的是“文件所有者”，而不是“文件组”。没有定义错误。
要清楚所提问题的含义。
如果没有为目录设置粘着位，则访问控制列表对于目录，其权限的工作方式如下：
- 所讨论的用户是该目录的所有者吗？
- 是 → 所有者的权限很重要。其他都不重要。结束程序。
- 否 → 该用户是否属于拥有该目录的组？
- 是 → 群组的权限很重要。其他都不重要。结束程序。
- 否 → 对方的权限很重要。结束程序。
目录的常见权限是rwxrwxr-x第二个rwx是组的权限。w它表示正确组中的任何用户都可以向目录中添加文件或从中删除文件（几乎，因为对于所有者来说，第一个w很重要，而不是第二个；如果是r-xrwxr-x实际所有者，即使所有者在该组中，也能比正确组的其他成员做得更少）。
当引用的问题是
有一个目录
/project，由组所有IT。用户peter和都stewie属于该组IT
它表明两者peter，并stewie可能删除目录中的任何文件，包括其他用户的文件。任务是将其更改为
创建的文件
peter无法被删除stewie
在设置粘性位之前，目录的“文件组”（这也是一个文件) 在从目录中删除文件时很重要。设置粘性位后，情况发生了变化。定义说“只有文件的所有者、目录的所有者或 root 用户可以 […] 删除”。对“文件组”的依赖不再成立。