SGID权限用于目录时，可使新创建的文件和子目录自动继承父目录的组ID，确保团队成员在共享目录中创建的文件归属同一项目组，便于协作。例如，设置chmod 2775 /project_share后，所有用户在此目录下创建的文件组均继承为developers组，提升权限管理效率。
Linux为目录设置特殊权限，通常我们指的是超越传统读、写、执行（rwx）模型的能力，这主要通过三种特殊权限位（SUID、SGID、Sticky Bit）来实现，当然，在更复杂的场景下，访问控制列表（ACL）提供了更精细的控制。这些机制让目录在文件创建、删除或权限继承上表现出与众不同的行为，从而满足特定的安全或协作需求。
为目录设置特殊权限，我们主要会用到
chmod命令，配合数字模式（八进制）或符号模式。
首先，我们得理解这三个特殊权限位对目录的作用：
- SUID (Set User ID)：对目录无效。SUID权限位通常用于可执行文件，让执行者以文件所有者的权限运行程序。但它对目录没有任何实际作用，即使设置了，系统也会忽略。
- SGID (Set Group ID)：这是针对目录非常重要的一个权限。当一个目录设置了SGID权限后，在该目录中创建的所有新文件和子目录都会自动继承父目录的组ID，而不是创建者用户的默认组ID。这在团队协作环境中尤其有用，可以确保所有新创建的文件都属于项目组。
-
Sticky Bit (粘滞位)：这个权限位对目录也至关重要。当一个目录设置了Sticky Bit后，即使用户对该目录有写权限，也只能删除或重命名自己拥有的文件，而不能删除或重命名其他用户的文件。最典型的例子就是
/tmp
目录，它就是为了防止用户随意删除他人文件而设置了Sticky Bit。
如何设置这些权限：
-
SGID (八进制模式)：在常规权限数字前加上
2
。例如，chmod 2775 /path/to/directory
。这里的2
就代表SGID。 -
SGID (符号模式)：
chmod g+s /path/to/directory
。g+s
表示为目录所属组添加SGID权限。 -
Sticky Bit (八进制模式)：在常规权限数字前加上
1
。例如，chmod 1777 /path/to/directory
。这里的1
就代表Sticky Bit。 -
Sticky Bit (符号模式)：
chmod +t /path/to/directory
。+t
表示为目录添加Sticky Bit。
如果需要同时设置SGID和Sticky Bit，比如像
/tmp目录那样，通常是
chmod 1777 /tmp（粘滞位，所有者读写执行，组读写执行，其他人读写执行）。如果需要SGID和Sticky Bit同时存在，那就是
chmod 3775 /path/to/directory(
3=
1(Sticky) +
2(SGID))。
此外，当传统的
rwx权限和特殊权限位仍不能满足需求时，Linux的访问控制列表 (ACL) 提供了一个更细粒度的权限管理方案。它允许你为特定的用户或组设置权限，而不仅仅是所有者、组和其他人。
什么是SGID权限？它在目录中的作用是什么？
SGID（Set Group ID）权限在目录中的作用，我个人觉得，在团队协作项目里简直是神来之笔。想象一下，你和你的团队成员都在一个共享的项目目录下工作，每个人创建文件时，如果按常规逻辑，这些文件会默认属于创建者自己的主组。这样一来，其他团队成员可能就没有足够的权限去修改或删除这些文件，导致权限混乱，工作效率直线下降。
SGID正是为了解决这个问题而生。当一个目录被设置了SGID权限（例如，
chmod 2775 /project_share），那么在这个目录下创建的任何新文件或子目录，都会自动继承这个父目录的组ID，而不是创建者用户的默认主组。这意味着，无论哪个团队成员在这个
project_share目录下创建了文件，这些文件都会自动归属于
project_share目录所属的那个项目组。
举个例子，如果
/project_share目录属于
developers组，并且设置了SGID，那么当用户
alice（主组
users）在这个目录下创建一个
report.txt文件时，
report.txt的组ID会是
developers，而不是
users。这样一来，所有属于
developers组的成员，都能根据目录的权限设置（比如
775）来访问
report.txt，大大简化了权限管理。
要设置SGID权限，你可以使用：
chmod g+s /path/to/directory
（符号模式，直观易懂）chmod 2775 /path/to/directory
（八进制模式，2
就是SGID位）
验证是否设置成功，可以用
ls -l命令，你会看到目录的组权限位上有一个
s（小写s表示SGID已设置且组有执行权限，大写S表示SGID已设置但组没有执行权限）。
# 假设 /project_share 目录当前权限是 drwxrwxr-x 属于 user:developers ls -ld /project_share # 输出: drwxrwxr-x. 2 user developers 4096 Apr 20 10:00 /project_share # 设置SGID权限 chmod g+s /project_share # 再次查看权限 ls -ld /project_share # 输出: drwxrwsr-x. 2 user developers 4096 Apr 20 10:00 /project_share # 注意 's' 出现在了组的执行位上 # 在此目录下创建一个文件，看看它的组 touch /project_share/new_file.txt ls -l /project_share/new_file.txt # 输出: -rw-rw-r--. 1 user developers 0 Apr 20 10:01 /project_share/new_file.txt # new_file.txt 的组是 developers，继承自父目录
这确实是一个非常实用的特性，尤其是在多用户共享文件系统或者版本控制系统的工作目录中，它能有效避免因权限问题导致的协作障碍。
Sticky Bit（粘滞位）在Linux目录中有什么实际用途？
Sticky Bit，或者叫粘滞位，这东西，初看可能觉得有点绕，但一想到
/tmp目录，立马就明白了它的精妙之处。它的核心作用是：在一个设置了Sticky Bit的目录里，即使你对这个目录有写入权限，你也只能删除或重命名你自己创建的文件，而不能动其他用户的文件。
这解决了什么问题呢？想象一下，我们有个公共的共享目录，比如
/tmp，所有用户都可以往里面写文件。如果这个目录没有Sticky Bit，那么任何用户都可以删除其他用户的文件，这显然会造成巨大的混乱和数据丢失。Sticky Bit就像给这个目录加了一道“君子协议”：你可以放你的东西进来，但你不能碰别人的东西。
最经典的例子就是Linux系统中的
/tmp目录。它的权限通常是
drwxrwxrwt。那个末尾的
t就代表了Sticky Bit。这意味着，任何用户都可以在
/tmp下创建文件，但只有文件的所有者（或者root用户，或者目录的所有者）才能删除或重命名这些文件。这对于一个临时文件存放区来说是至关重要的，它确保了用户之间互不干扰，维护了系统的稳定性和安全性。
要设置Sticky Bit权限，你可以使用：
chmod +t /path/to/directory
（符号模式）chmod 1777 /path/to/directory
（八进制模式，1
就是Sticky Bit位）
验证是否设置成功，同样用
ls -l命令，你会看到目录的“其他”权限位上有一个
t（小写t表示Sticky Bit已设置且其他用户有执行权限，大写T表示Sticky Bit已设置但其他用户没有执行权限）。
# 查看 /tmp 目录的权限 ls -ld /tmp # 输出: drwxrwxrwt. 12 root root 4096 Apr 20 09:50 /tmp # 注意末尾的 't' # 模拟用户A在 /tmp 创建文件 # (假设我当前是 userA) touch /tmp/userA_file.txt # 模拟用户B在 /tmp 创建文件 # (切换到 userB) # touch /tmp/userB_file.txt # 现在，userA 尝试删除 userB 的文件 # rm /tmp/userB_file.txt # 这会失败，并提示“Operation not permitted”
Sticky Bit是Linux文件系统安全机制中一个不起眼但极其有效的设计，它在多用户环境下为共享目录提供了一种基本的防篡改保护。
如何使用ACL（访问控制列表）为Linux目录设置更精细的权限？
传统的
chmod权限模型固然强大，但有时候，它就是显得有点“粗犷”。比如，你想让某个特定用户对某个目录有写权限，但又不想把他加入到目录所属的组里，或者你想给一个用户A读写权限，给用户B只读权限，而用户A和用户B都不属于目录的组，这时候传统的
rwx就有点力不从心了。这时，访问控制列表（ACL） 就成了我们的救星，它允许我们为文件和目录设置更细粒度的权限。
ACL是文件系统权限的一个扩展，它允许为任意数量的用户或组设置权限，而不仅仅是所有者、组和其他人这三类。这在复杂的权限需求场景下非常有用。
使用ACL，我们主要会用到两个命令：
getfacl
：用于查看文件或目录的ACL权限。setfacl
：用于设置文件或目录的ACL权限。
在开始使用ACL之前，你需要确保你的文件系统（如ext4, XFS）支持ACL，并且已经挂载时启用了ACL选项（通常默认已启用）。
查看ACL权限：
getfacl /path/to/directory
输出会显示文件所有者、组、其他人的权限，以及任何额外的ACL条目。
设置ACL权限：
setfacl命令提供了多种选项：
-m
(modify): 修改或添加ACL条目。-x
(remove): 移除ACL条目。-b
(remove all): 移除所有ACL条目。-d
(default): 设置默认ACL，对在该目录下创建的新文件和子目录生效。
示例1：给特定用户添加读写权限
假设我们有一个目录
/data/shared_project，我们想让用户
john对它有读写权限，而
john不属于
shared_project的组。
# 给用户john添加读写权限 setfacl -m u:john:rw /data/shared_project # 验证 getfacl /data/shared_project # 输出中会多一行：user:john:rw-
示例2：给特定组添加只读权限
假设我们想让
analysts组对该目录有只读权限。
# 给组analysts添加只读权限 setfacl -m g:analysts:r /data/shared_project # 验证 getfacl /data/shared_project # 输出中会多一行：group:analysts:r--
示例3：设置默认ACL权限
这是ACL一个非常强大的功能。如果你希望在
/data/shared_project目录下创建的所有新文件和子目录都自动继承某些ACL权限，你可以设置默认ACL。
# 设置默认ACL：所有新文件和子目录，用户john拥有读写权限 setfacl -m d:u:john:rw /data/shared_project # 现在在这个目录下创建一个新文件或子目录，它会自动继承这个默认ACL cd /data/shared_project mkdir new_subdir touch new_file.txt getfacl new_subdir # 会看到 new_subdir 继承了 u:john:rw- 的权限 getfacl new_file.txt # 同样，new_file.txt 也会有 u:john:rw- 的权限
移除ACL条目：
# 移除用户john的ACL权限 setfacl -x u:john /data/shared_project # 移除所有ACL条目（包括默认ACL） setfacl -b /data/shared_project
使用ACL虽然功能强大，但也增加了权限管理的复杂性。在实际操作中，我建议先尝试传统的
chmod和特殊权限位，如果它们确实无法满足需求，再考虑引入ACL。因为过度复杂的ACL设置可能会让权限调试变得困难。但不可否认，在需要精细控制访问权限的场景下，ACL是不可或缺的利器。
