SGID权限用于目录时，可使新创建的文件和子目录自动继承父目录的组ID，确保团队成员在共享目录中创建的文件归属同一项目组，便于协作。例如，设置chmod 2775 /project_share后，所有用户在此目录下创建的文件组均继承为developers组，提升权限管理效率。

Linux为目录设置特殊权限，通常我们指的是超越传统读、写、执行（rwx）模型的能力，这主要通过三种特殊权限位（SUID、SGID、Sticky Bit）来实现，当然，在更复杂的场景下，访问控制列表（ACL）提供了更精细的控制。这些机制让目录在文件创建、删除或权限继承上表现出与众不同的行为，从而满足特定的安全或协作需求。

为目录设置特殊权限，我们主要会用到

chmod

命令，配合数字模式（八进制）或符号模式。

首先，我们得理解这三个特殊权限位对目录的作用：

1. SUID (Set User ID)：对目录无效。SUID权限位通常用于可执行文件，让执行者以文件所有者的权限运行程序。但它对目录没有任何实际作用，即使设置了，系统也会忽略。
2. SGID (Set Group ID)：这是针对目录非常重要的一个权限。当一个目录设置了SGID权限后，在该目录中创建的所有新文件和子目录都会自动继承父目录的组ID，而不是创建者用户的默认组ID。这在团队协作环境中尤其有用，可以确保所有新创建的文件都属于项目组。
3. 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文件系统安全机制中一个不起眼但极其有效的设计，它在多用户环境下为共享目录提供了一种基本的防篡改保护。

博思AIPPT

博思aiPPT来了，海量PPT模板任选，零基础也能快速用AI制作PPT。

41

查看详情

如何使用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是不可或缺的利器。