openEuler 20.03 普通用户su切换root权限受阻的排查与两种修复方案

1. 问题现象与初步分析

最近在openEuler 20.03系统上遇到一个典型问题：普通用户admin尝试用su命令切换到root时，系统直接返回"拒绝权限"的错误提示。这个现象看似简单，但背后涉及Linux系统的安全机制设计。先来看具体报错：

[admin@localhost ~]$ su - 密码： su: 拒绝权限

这种情况在刚接触openEuler的新手中相当常见。我第一次遇到时也花了些时间排查，后来发现这是openEuler基于PAM（可插拔认证模块）的安全策略在起作用。简单来说，系统默认只允许特定用户组的成员执行su切换操作，这是为了防止任意用户都能获取root权限导致的安全风险。

2. 深入理解PAM机制

2.1 PAM是什么

PAM（Pluggable Authentication Modules）是Linux系统的认证框架，它通过模块化的方式管理系统认证流程。在openEuler 20.03中，与su命令相关的PAM配置文件位于/etc/pam.d/su。这个文件决定了哪些用户、在什么条件下可以切换身份。

我查看过多个Linux发行版的PAM配置，发现openEuler的默认配置确实更严格。这种设计理念值得肯定——毕竟安全无小事。但这也给日常运维带来了一些小麻烦，需要我们知道如何合理调整。

2.2 关键配置项分析

打开/etc/pam.d/su文件，会看到这样一行关键配置：

auth required pam_wheel.so use_uid

这行配置的意思是：只有wheel用户组的成员才能使用su命令切换为root。wheel组在Unix-like系统中传统上就是"特权用户组"，openEuler延续了这个设计理念。

3. 解决方案一：修改PAM配置

3.1 操作步骤

第一种解决方案是直接修改PAM配置，这也是最快速的方法：

1. 先用root身份编辑配置文件：

vi /etc/pam.d/su

2. 找到包含pam_wheel.so的那行，在前面加上#号注释掉：

#auth required pam_wheel.so use_uid

3. 保存退出后，新开终端窗口测试：

[admin@localhost ~]$ su - 密码： [root@localhost ~]#

3.2 安全考量

这种方法虽然简单，但从安全角度我并不推荐长期使用。它相当于完全放开了su权限限制，任何知道root密码的用户都能切换身份。在生产环境中，这可能会带来安全隐患。

不过如果是个人开发环境，或者确实需要完全放开权限的场景，这个方法确实简单有效。我在测试环境中就经常这么处理，毕竟方便性也很重要。

4. 解决方案二：调整用户组

4.1 详细操作步骤

第二种方案更符合安全最佳实践——将需要su权限的用户加入wheel组：

1. 使用root执行以下命令：

usermod -G wheel admin

2. 验证用户是否已加入wheel组：

grep wheel /etc/group

应该能看到类似输出：

wheel:x:10:admin

3. 新开终端测试su切换：

[admin@localhost ~]$ su - 密码： [root@localhost ~]#

4.2 原理与优势

这种方法的核心思想是"最小权限原则"——只给确实需要的用户授权。相比第一种方案，它有明显优势：

1. 保持了系统的安全基线
2. 可以精确控制哪些用户有su权限
3. 符合企业级环境的安全管理要求

我在生产环境中都采用这种方式，配合sudo权限的精细分配，既能满足日常运维需求，又能最大限度降低安全风险。

5. 两种方案的对比与选择

5.1 功能对比

5.2 选择建议

根据我的经验，给出以下实用建议：

1. 如果是个人电脑或开发测试环境，追求便利性，可以选择方案一
2. 如果是生产服务器，强烈建议采用方案二
3. 在方案二基础上，可以结合sudo权限分配，实现更精细的权限控制
4. 无论采用哪种方案，都要确保root密码的强度和安全保管

6. 常见问题排查

6.1 修改后仍无法su

有时候即使按照上述步骤操作，问题可能依然存在。我遇到过几次这种情况，通常是因为：

1. 用户没有重新登录：组权限变更需要用户重新登录才能生效
2. 存在多个PAM配置文件冲突：检查/etc/pam.d/下其他相关配置
3. SELinux策略限制：可以暂时将SELinux设为permissive模式测试

6.2 其他相关命令

除了su命令，这些命令也很有用：

1. 查看用户所属组：

groups admin

2. 临时切换组身份：

newgrp wheel

3. 检查PAM模块文档：

man pam_wheel

7. 安全加固建议

虽然解决了su权限问题，但安全防护不能松懈。分享几个我在实际工作中的经验：

1. 定期审计wheel组成员：确保只有必要用户拥有权限
2. 配置sudo替代部分su场景：更细粒度的控制命令权限
3. 启用SSH密钥认证：减少密码泄露风险
4. 配置fail2ban防护暴力破解
5. 定期检查auth日志：

grep 'su:' /var/log/auth.log

8. 延伸思考

这个问题看似简单，但反映了Linux系统权限管理的核心理念。openEuler默认的严格配置其实是个好设计，它迫使管理员必须明确授权，而不是随意使用root权限。

我在团队内部推行"最小权限原则"时，就经常用这个案例来说明：不是系统难用，而是安全需要。随着云原生和容器化的发展，直接使用root的场景其实在减少，这也是技术演进的一个有趣现象。