解决su命令执行失败：SELinux与文件权限深度排查

1. 问题现象与初步分析

那天在服务器上执行常规维护时，遇到了一个诡异的情况：当我以root身份尝试切换到普通用户时，系统突然报错"su: failed to execute /bin/bash: Permission denied"。这个错误看似简单，实则暗藏玄机。作为运维老手，我立刻意识到这不是普通的权限问题，而是系统关键组件出现了异常。

首先我们需要理解su命令的执行流程：当输入"su username"时，系统会做以下几件事：

1. 检查目标用户的shell配置（通常是/bin/bash）
2. 验证密码（如果是非root用户切换）
3. 加载目标用户的环境变量
4. 启动指定的shell程序

2. 深度排查过程

2.1 文件权限检查

我首先检查了/bin/bash的权限：

bash复制ls -l /bin/bash

发现输出显示权限正常（-rwxr-xr-x），属主是root。这排除了最基本的权限问题。

2.2 SELinux状态验证

接着我检查了SELinux的状态：

bash复制sestatus

发现SELinux处于Enforcing模式。这可能是问题的根源之一，因为SELinux可能会限制某些上下文切换。

2.3 文件系统挂载选项

检查文件系统挂载选项：

bash复制mount | grep ' / '

发现根文件系统挂载时带有nosuid选项，这会影响setuid程序的执行。

2.4 系统日志分析

查看系统日志寻找线索：

bash复制journalctl -xe

在日志中发现多条与SELinux相关的拒绝记录，确认了SELinux确实是问题的关键因素。

3. 解决方案实施

3.1 临时解决方案

如果需要立即恢复功能，可以临时将SELinux设为Permissive模式：

bash复制setenforce 0

但这只是临时措施，不建议在生产环境长期使用。

3.2 永久解决方案

正确的做法是修复SELinux上下文：

bash复制restorecon -v /bin/bash

然后检查并修复相关文件的上下文：

bash复制restorecon -R /usr/bin
restorecon -R /etc

3.3 文件系统挂载修正

如果问题由nosuid挂载选项引起，需要修改/etc/fstab文件，移除相关分区的nosuid选项，然后重新挂载：

bash复制mount -o remount /

4. 预防措施与最佳实践

4.1 定期检查系统关键文件

建议建立定期检查机制：

bash复制#!/bin/bash
critical_files=("/bin/bash" "/bin/su" "/usr/bin/passwd")
for file in "${critical_files[@]}"; do
    ls -lZ $file >> /var/log/file_check.log
done

4.2 SELinux策略定制

对于需要特殊权限的应用，应该创建自定义SELinux策略模块：

bash复制ausearch -m avc -ts recent | audit2allow -M mypolicy
semodule -i mypolicy.pp

4.3 文件系统监控

部署实时文件系统监控：

bash复制yum install auditd
auditctl -w /bin/bash -p war -k bash_changes

5. 深入原理分析

5.1 su命令的工作机制

su命令实际上是一个setuid程序，它的执行流程涉及：

1. 内核检查setuid位
2. 切换有效用户ID
3. 加载目标用户环境
4. 执行目标shell

5.2 SELinux的影响机制

SELinux通过类型强制（TE）和基于角色的访问控制（RBAC）来限制进程行为。当上下文不匹配时，即使传统权限允许，操作也会被拒绝。

5.3 文件系统特性的影响

nosuid挂载选项会禁用该文件系统上所有setuid和setgid位的效果，这是出于安全考虑的设计。

6. 扩展场景与变种问题

6.1 其他常见错误变种

• "su: cannot set user id: Resource temporarily unavailable"：通常由进程数限制引起
• "su: warning: cannot change directory to /home/user: Permission denied"：主目录权限问题
• "su: Authentication failure"：密码或PAM配置问题

6.2 容器环境中的特殊考量

在Docker等容器环境中，可能需要额外注意：

bash复制docker run --security-opt label=disable ...

来禁用SELinux限制。

7. 自动化检测脚本

以下是一个综合检测脚本，可以快速诊断相关问题：

bash复制#!/bin/bash
echo "### 系统基本信息 ###"
uname -a
echo -e "\n### SELinux状态 ###"
sestatus
echo -e "\n### 关键文件权限 ###"
ls -lZ /bin/bash /bin/su
echo -e "\n### 文件系统挂载选项 ###"
mount | grep -E ' / | /usr | /bin'
echo -e "\n### 最近SELinux拒绝日志 ###"
ausearch -m avc -ts recent 2>/dev/null | head -n 20

8. 恢复流程标准化

建议将恢复流程标准化为以下步骤：

1. 检查SELinux状态和模式
2. 验证关键文件权限和上下文
3. 检查文件系统挂载选项
4. 分析系统日志
5. 根据发现的问题采取针对性措施
6. 记录问题和解决方案

9. 性能与安全权衡

在解决此类问题时，需要权衡：

• 完全禁用SELinux带来的安全风险
• 过度限制导致的功能异常
• 维护成本与安全收益的平衡

建议的方案是保持SELinux启用，但针对特定需求定制策略，而不是简单地完全禁用安全功能。

10. 历史案例参考

在某次实际案例中，系统更新后出现了类似问题。原因是：

1. 更新包修改了/bin/bash的上下文
2. 但未正确刷新文件系统缓存
3. 导致su命令无法正确执行

解决方案是：

bash复制restorecon -R /bin
touch /.autorelabel
reboot

这个案例说明，即使是常规系统更新，也可能引发此类问题。