Linux文件权限进阶：为什么你的passwd命令能修改shadow文件？

Linux文件权限进阶：为什么你的passwd命令能修改shadow文件？

你是否曾经好奇过，为什么普通用户能够通过passwd命令修改自己的密码，而/etc/shadow文件却显示没有任何权限？这背后隐藏着Linux权限系统的精妙设计——特殊权限机制。本文将带你深入探索SUID、SGID和Sticky Bit这三种特殊权限的工作原理与实际应用场景。

1. 从日常运维现象看权限谜题

在Linux系统中，/etc/shadow文件存储着所有用户的密码哈希值，其默认权限设置如下：

$ ls -l /etc/shadow ---------- 1 root root 1575 Oct 5 22:48 /etc/shadow

这个输出显示该文件对所有用户（包括属主root、属组root和其他用户）都没有任何访问权限。然而，任何普通用户却都能通过passwd命令成功修改自己的密码。这个看似矛盾的现象，正是SUID权限发挥作用的典型案例。

观察/usr/bin/passwd的权限设置：

$ ls -l /usr/bin/passwd -rwsr-xr-x. 1 root root 27832 Jun 10 2014 /usr/bin/passwd

注意属主执行权限位上的s标志，这就是SUID权限的视觉标识。当普通用户执行这个命令时，系统会临时赋予该进程文件属主（root）的权限，从而突破常规权限限制。

2. SUID权限深度解析

2.1 SUID工作机制

SUID（Set User ID）是三种特殊文件权限中最常用的一种，其核心特点包括：

• 权限提升：执行带有SUID位的程序时，进程的有效用户ID（EUID）会被设置为文件属主的UID
• 临时性：权限提升仅在该程序运行期间有效
• 安全限制：
  • 仅对二进制可执行文件有效
  • 对脚本文件设置SUID通常无效（取决于系统配置）
  • 必须具有可执行权限才能生效

2.2 典型应用场景

除了passwd命令，Linux系统中常见的SUID程序还包括：

提示：在生产环境中应定期审计SUID程序，使用find / -perm -4000 -type f命令可列出所有设置了SUID位的文件。

2.3 SUID权限管理实践

设置和移除SUID权限有两种方式：

字母表示法：

# 添加SUID权限 chmod u+s /path/to/file # 移除SUID权限 chmod u-s /path/to/file

数字表示法：

# 添加SUID权限（4开头） chmod 4755 /path/to/file # 移除SUID权限（0开头） chmod 0755 /path/to/file

实际案例：调试SUID权限的影响

# 备份原始passwd命令 cp /usr/bin/passwd /tmp/passwd.bak # 移除SUID权限测试 chmod u-s /usr/bin/passwd # 尝试修改密码（将失败） passwd Changing password for user test. passwd: Authentication token manipulation error # 恢复SUID权限 chmod u+s /usr/bin/passwd

3. SGID权限的协作优势

3.1 SGID的核心特性

SGID（Set Group ID）与SUID类似，但关注的是组权限：

• 对文件：运行时进程获得文件属组的权限
• 对目录：在该目录下创建的新文件继承目录的属组

查看SGID权限的标志：

$ ls -ld /var/local drwxrwsr-x 2 root staff 4096 Aug 12 10:34 /var/local

注意属组权限位的s标志，表示设置了SGID。

3.2 实际应用案例

项目协作目录配置：

1. 创建共享目录并设置SGID：

mkdir /project chown :devteam /project chmod 2775 /project

2. 验证权限：

ls -ld /project drwxrwsr-x 2 root devteam 4096 Aug 12 11:20 /project

3. 不同用户创建文件测试：

# 用户A创建文件 su - userA -c "touch /project/fileA.txt" # 用户B创建文件 su - userB -c "touch /project/fileB.txt" # 检查文件属组 ls -l /project -rw-r--r-- 1 userA devteam 0 Aug 12 11:22 fileA.txt -rw-r--r-- 1 userB devteam 0 Aug 12 11:22 fileB.txt

3.3 SGID权限管理

设置SGID权限的两种方式对比：

4. Sticky Bit的防误删保护

4.1 Sticky Bit的起源与作用

Sticky Bit最初设计用于保持程序在交换区驻留，现代Linux系统中主要用于目录，实现：

• 仅文件所有者可以删除/重命名自己的文件
• root用户不受此限制
• 典型应用：系统的/tmp目录

查看示例：

$ ls -ld /tmp drwxrwxrwt 12 root root 4096 Aug 12 12:00 /tmp

注意其他用户权限位的t标志，表示设置了Sticky Bit。

4.2 实际配置演示

共享临时目录配置：

1. 创建测试目录：

mkdir /shared_tmp chmod 1777 /shared_tmp

2. 多用户测试：

# 用户A操作 su - userA -c "touch /shared_tmp/fileA && ls -l /shared_tmp/fileA" -rw-r--r-- 1 userA userA 0 Aug 12 12:05 /shared_tmp/fileA # 用户B尝试删除 su - userB -c "rm -f /shared_tmp/fileA" rm: cannot remove '/shared_tmp/fileA': Operation not permitted # 用户A自己可以删除 su - userA -c "rm -f /shared_tmp/fileA"

4.3 权限管理命令

Sticky Bit的设置方法对比：

5. 安全实践与风险防控

5.1 特殊权限的安全风险

不恰当的SUID/SGID设置可能带来严重安全隐患：

• 提权漏洞：如果SUID程序存在漏洞，可能被利用获取root权限
• 信息泄露：不当的SGID设置可能导致敏感数据被非授权访问
• 资源滥用：Sticky Bit配置不当可能影响系统临时文件管理

5.2 安全审计方法

定期检查特殊权限设置：

# 查找所有SUID文件 find / -perm -4000 -type f -exec ls -ld {} \; 2>/dev/null # 查找所有SGID文件 find / -perm -2000 -type f -exec ls -ld {} \; 2>/dev/null # 查找可写的SUID/SGID文件（高危！） find / -perm -4000 -type f -writable 2>/dev/null find / -perm -2000 -type f -writable 2>/dev/null

5.3 最佳实践建议

1. 最小权限原则：

   • 只为绝对必要的程序设置SUID/SGID
   • 使用专用账户而非root作为SUID程序的属主

2. 定期审计：

   • 建立特殊权限文件的白名单
   • 监控非标准位置的SUID/SGID文件

3. 替代方案考虑：

   • 使用capabilities替代部分SUID场景
   • 考虑sudo授权代替SUID提权

# 使用getcap查看文件的capabilities getcap /usr/bin/ping /usr/bin/ping = cap_net_raw+ep

在多年的Linux系统管理实践中，我发现特殊权限就像一把双刃剑——合理使用能极大提升系统管理的灵活性，但滥用则可能成为安全噩梦。最深刻的教训来自一次SUID后门检查，一个被遗忘的测试脚本保留了SUID root权限，差点成为入侵者的跳板。从那以后，我养成了每月审计特殊权限的习惯，并建立了严格的白名单制度。