Linux怎么使用chmod配置文件的特殊权限位

P粉602998670

发布时间：2025-09-10 08:01:01

890人浏览过

来源于php中文网

原创

答案：linux中chmod命令用于设置suid、sgid和sticky bit特殊权限，分别通过4000、2000、1000八进制值实现，可用于提升执行权限或保护共享目录，但需防范滥用导致的安全风险，应定期审计并遵循最小权限原则。

linux怎么使用chmod配置文件的特殊权限位

在Linux系统中，

chmod

命令用于配置文件的特殊权限位，主要是指SetUID (SUID)、SetGID (SGID) 和 Sticky Bit。这些权限位赋予文件或目录额外的行为特性，超越了传统的用户、组、其他用户的读、写、执行权限。通过八进制数字模式（如

4xxx

、

2xxx

、

1xxx

）或符号模式（如

u+s

、

g+s

、

o+t

），我们可以精确控制这些特殊权限，它们在特定场景下极为有用，但若滥用，也可能带来显著的安全隐患。

解决方案

特殊权限位，在我看来，是Linux权限管理中一个既强大又有点“双刃剑”色彩的功能。它们不只是简单的读写执行，更像是给文件或目录附加了某种行为模式。理解并正确运用它们，对于系统管理员和开发者来说，是提升系统功能性和安全性的关键。

首先，我们来聊聊这三个特殊的权限位：

SetUID (SUID)：当一个可执行文件被设置了SUID权限时，任何用户在执行这个文件时，都会暂时获得文件所有者的权限。最经典的例子就是
```
passwd
```
命令。普通用户执行
```
passwd
```
修改自己的密码时，需要写入
```
/etc/shadow
```
文件，而这个文件只有root用户才有写权限。通过给
```
passwd
```
命令设置SUID，它就能以root的身份运行，从而完成密码修改。在
```
ls -l
```
的输出中，SUID权限会显示为文件所有者执行位上的
```
s
```
（如果所有者本身有执行权限）或
```
s
```
（如果没有执行权限）。八进制表示为
```
4000
```
。
SetGID (SGID)：SGID有两种主要用途。
- 对于可执行文件：与SUID类似，当执行一个设置了SGID权限的可执行文件时，用户会暂时获得文件所属组的权限。
- 对于目录：这是SGID更常见且更有趣的应用。如果一个目录设置了SGID权限，那么在该目录下创建的新文件或子目录，其所属组将自动继承父目录的所属组，而不是创建者用户的默认组。这对于团队协作，共享文件管理非常有用。同样，在
```
ls -l
```
  输出中，SGID权限显示为文件所属组执行位上的
```
s
```
  或
```
s
```
  。八进制表示为
```
2000
```
  。
Sticky Bit (粘滞位)：Sticky Bit主要用于目录。当一个目录设置了Sticky Bit权限时，即使目录对所有用户都可写，也只有文件的所有者、目录的所有者或者root用户才能删除或重命名该目录下的文件。这极大地防止了共享目录中的“误操作”或恶意删除。最典型的应用场景就是
```
/tmp
```
目录，所有用户都可以在里面创建文件，但不能删除别人的文件。在
```
ls -l
```
输出中，Sticky Bit显示为“其他用户”执行位上的
```
t
```
或
```
t
```
。八进制表示为
```
1000
```
。

如何使用

chmod

设置这些权限？

我们可以通过八进制数字模式或符号模式来操作：

八进制模式：在传统的
```
rwx
```
权限数字（0-7）前面加上一个表示特殊权限的数字。
- ```
4
```
  代表SUID
- ```
2
```
  代表SGID
- ```
1
```
  代表Sticky Bit
- 例如，
```
chmod 4755 myfile
```
  会给
```
myfile
```
  设置SUID权限，同时其常规权限为
```
rwxr-xr-x
```
  。
- ```
chmod 2770 mydir
```
  会给
```
mydir
```
  设置SGID权限，同时其常规权限为
```
rwxrwx---
```
  。
- ```
chmod 1777 /tmp/shared
```
  会给
```
/tmp/shared
```
  设置Sticky Bit权限，同时其常规权限为
```
rwxrwxrwx
```
  。
- 你可以将这些数字相加来组合使用，比如
```
chmod 6755
```
  （SUID + SGID + rwxr-xr-x）。
符号模式：更直观，使用
```
u+s
```
、
```
g+s
```
、
```
o+t
```
来添加，
```
u-s
```
、
```
g-s
```
、
```
o-t
```
来移除。
- ```
chmod u+s myfile
```
  ：给
```
myfile
```
  添加SUID权限。
- ```
chmod g+s mydir
```
  ：给
```
mydir
```
  添加SGID权限。
- ```
chmod o+t /tmp/shared
```
  ：给
```
/tmp/shared
```
  添加Sticky Bit权限。
- ```
chmod u-s,g-s myfile
```
  ：移除
```
myfile
```
  的SUID和SGID权限。

在我看来，符号模式在日常操作中更易读，但八进制模式在脚本或需要精确控制时显得更简洁有力。

什么时候应该谨慎使用SUID和SGID权限？

坦白说，SUID和SGID权限，尤其是SUID，是系统安全中最容易被忽视的“雷区”之一。它们的存在本身是为了解决特定问题，比如让普通用户执行某些需要特权的操作。然而，一旦某个设置了SUID或SGID的程序存在漏洞，或者被设计不当，就可能成为攻击者提升权限的跳板。

SUID的潜在风险：设想一下，如果一个由root拥有的、并设置了SUID权限的程序，允许用户输入任意命令来执行，那简直就是给攻击者开了个后门。即使程序本身没有明显的漏洞，如果它能以root权限执行其他程序，比如

bash

，那么普通用户就能通过这个SUID程序获取一个root shell。我记得几年前，就有人利用

find

命令的SUID权限（如果它被错误地设置为SUID）来执行任意命令，因为

find

的

-exec

参数可以执行外部程序。这简直是灾难性的。因此，只有那些经过严格安全审计、功能单一且不接受用户输入作为可执行代码的程序，才应该被赋予SUID权限。

SGID的潜在风险：对于可执行文件，SGID的风险与SUID类似，只是权限提升到文件所属组。如果这个组拥有敏感资源的访问权限，同样可能造成安全问题。对于目录，SGID虽然主要是为了协作方便，但如果目录的组权限设置不当（比如对所有用户开放写权限，且该组拥有对系统关键配置文件的写权限），也可能被滥用。

我的建议是：

最小化原则：尽可能少地使用SUID和SGID。除非绝对必要，否则不要为任何文件设置这些权限。
脚本的禁忌：永远不要给脚本（如Shell脚本、Python脚本等）设置SUID或SGID权限。因为SUID/SGID权限是作用于解释器（如
```
/bin/bash
```
），而不是脚本本身。这意味着攻击者可以创建一个恶意脚本，然后通过SUID/SGID解释器来执行它，从而获得特权。
定期审计：定期检查系统上哪些文件拥有SUID或SGID权限，并评估其必要性和安全性。这通常通过
```
find
```
命令完成，稍后我们会详细讨论。
来源可信：确保所有带有SUID/SGID权限的程序都来自可信赖的软件包或经过严格的安全测试。

如何利用Sticky Bit有效管理共享目录？

在我多年的经验里，Sticky Bit简直是共享目录的“救星”。想象一下一个开发团队，大家需要在一个公共目录下共享代码、上传测试文件，或者一个Web服务器的上传目录，用户可以上传头像或附件。如果没有Sticky Bit，只要目录对所有用户可写，任何用户都可以随意删除或修改其他用户上传的文件。这很快就会演变成一场数字混乱，甚至可能导致数据丢失。

问题场景： 假设我们有一个

/opt/project_data

目录，团队成员

userA

、

userB

都需要往里面放文件。

# 创建目录并设置所有人可写
sudo mkdir /opt/project_data
sudo chmod 777 /opt/project_data

# userA创建文件
su - userA
touch /opt/project_data/file_by_A
exit

# userB删除userA的文件
su - userB
rm /opt/project_data/file_by_A # 成功删除！
exit

这显然不是我们想要的。

Sticky Bit的解决方案： 给

/opt/project_data

目录设置Sticky Bit。

sudo chmod +t /opt/project_data
# 或者使用八进制：sudo chmod 1777 /opt/project_data
# 检查权限：
ls -ld /opt/project_data
# 输出可能类似：drwxrwxrwt. 2 root root 4096 Apr 23 10:00 /opt/project_data
# 注意末尾的't'

现在，我们再来重复上面的操作：

MeloCool

AI歌曲生成器 - 歌词转歌曲AI音乐制作器在线工具

下载

# userA创建文件
su - userA
touch /opt/project_data/file_by_A
exit

# userB删除userA的文件
su - userB
rm /opt/project_data/file_by_A
# rm: cannot remove '/opt/project_data/file_by_A': Operation not permitted
exit

看，

userB

就无法删除

userA

的文件了。这就是Sticky Bit的魅力所在。它确保了目录中的文件只能由其所有者、目录所有者或root用户删除或重命名，极大地提升了共享目录的可用性和数据完整性。这在我看来，是每个系统管理员都应该掌握的实用技巧。

检查系统中存在哪些特殊权限文件，并识别潜在的安全风险？

作为一名负责任的系统管理员，定期对系统进行安全审计是必不可少的。而查找并审查特殊权限文件，尤其是SUID和SGID文件，是这项工作的重要组成部分。因为这些文件一旦被恶意利用，后果不堪设想。

查找SUID和SGID文件：

我通常会使用

find

命令来完成这项任务。

find / -perm /4000 -o -perm /2000 2>/dev/null

让我来解释一下这条命令：

```
find /
```
：从根目录开始搜索整个文件系统。
```
-perm /4000
```
：查找所有设置了SUID权限的文件。这里的
```
/
```
前缀表示“只要权限位中的任何一个被设置，就匹配”。
```
-o
```
：逻辑OR操作符，表示“或”。
```
-perm /2000
```
：查找所有设置了SGID权限的文件。
```
2>/dev/null
```
：将所有错误输出（例如“Permission denied”）重定向到
```
/dev/null
```
，这样我们只会看到有权限访问的文件的列表，避免屏幕被大量错误信息刷屏。

这条命令会列出系统中所有带有SUID或SGID权限的文件。

识别潜在的安全风险：

拿到这个列表后，我的下一步就是逐一审查。这有点像侦探工作，需要细心和经验：

审查已知系统文件：
- 许多标准的系统命令（如
```
passwd
```
  ,
```
sudo
```
  ,
```
mount
```
  ,
```
ping
```
  等）是需要SUID权限的，这是正常的。你需要确认这些文件的路径和哈希值是否与系统包管理器的记录一致，以防被恶意替换。
- 对于那些看起来正常的系统文件，如果其权限被修改，或者文件大小、修改时间异常，这可能是一个警报。
查找非标准文件：
- 特别关注那些位于非标准路径（如
```
/tmp
```
  ,
```
/var/tmp
```
  , 用户主目录下的隐藏目录）或者看起来命名奇怪的文件。
- 任何由普通用户拥有的，但设置了SUID或SGID权限的文件，都应该被高度怀疑。
- 脚本文件（以
```
.sh
```
  ,
```
.py
```
  等结尾，或者文件头部有
```
#!
```
  解释器声明）如果被设置了SUID/SGID，几乎可以肯定是严重的风险。我前面提到过，这是因为权限作用于解释器，而不是脚本本身。
检查文件内容：
- 对于可疑的SUID/SGID文件，如果你是开发者，可以尝试逆向工程或查看其源代码。如果只是普通用户，至少要确保它是你系统上合法且最新的二进制文件。

如何处理风险？

移除不必要的权限：如果某个文件不应该拥有SUID或SGID权限，立即移除它。例如：
```
chmod u-s /path/to/file
```
或
```
chmod g-s /path/to/file
```
。
更新或删除可疑文件：如果发现被篡改的系统文件或恶意文件，应立即将其删除，并从可信来源重新安装或恢复。
加强监控：对于关键的SUID/SGID文件，可以设置文件完整性监控（如使用
```
aide
```
或
```
tripwire
```
），以便在它们被修改时立即收到警报。

查找Sticky Bit目录：

查找Sticky Bit目录相对简单，风险也小得多，主要是为了确保共享目录的配置符合预期。