sudo -l 不显示 nopasswd 不代表权限未生效，因其仅列出显式匹配的命令规则，不展开组规则或显示密码策略；用户属 wheel 组且 %wheel all=(all) nopasswd 配置正确时，sudo whoami 可成功，但 systemctl 等命令失败常因 d-bus/session 限制而非 sudo 权限问题。
sudo -l 看不到 NOPASSWD 权限，但 %wheel ALL=(ALL) NOPASSWD 已配好
这说明配置确实生效了，但 sudo -l 默认只显示当前用户**显式匹配到的规则**，而 %wheel 是组规则，它不会在 sudo -l 输出里展开成具体命令列表——除非你属于 wheel 组且该组规则被解析到了。
常见错误现象：sudo -l 返回 Matching Defaults entries for user on host: 后直接结束，没报错也没权限行；但 sudo whoami 却能成功返回 root。
- 确认用户是否真在
wheel组：id -nG查看输出里有没有wheel - 检查
/etc/sudoers中%wheel行是否被后续规则覆盖（比如某条Defaults targetpw或更早的%wheel ALL=(ALL) ALL会覆盖 NOPASSWD） -
sudo -l不显示NOPASSWD并不等于没生效，它只反映“可运行哪些命令”，不反映“是否要密码”
为什么 sudo whoami 成功，但 sudo systemctl restart nginx 失败？
因为 %wheel ALL=(ALL) NOPASSWD 允许提权任意命令，但某些命令（如 systemctl）实际调用的是 systemd 的 socket 或 D-Bus 接口，而这些接口有自己的一套权限控制，和 sudo 无关。
使用场景：想用 sudo 运行服务管理命令，却卡在 Failed to connect to bus: Operation not permitted 或 Access denied。
- 根本原因不是 sudo 权限问题，而是
systemctl在非登录 shell（如脚本、SSH 单命令）中无法读取用户 session bus 地址 - 临时解决：加
-i模拟交互登录 shell：sudo -i systemctl restart nginx - 长期方案：改用
sudo /bin/systemctl并确保 systemd 配置允许非 session 调用（需调整/etc/dbus-1/system.d/org.freedesktop.systemd1.conf）
sudoers 中 %wheel ALL=(ALL) NOPASSWD 生效但部分命令仍要密码
这是规则顺序和匹配逻辑导致的——sudo 从上到下逐行匹配，一旦某条规则明确拒绝或限制了某个命令，就不会继续往后看。
参数差异：NOPASSWD 必须紧贴在命令定义之后，不能被空格或注释隔开；且如果同一用户/组有多条规则，后出现的可能覆盖前一条。
- 错误写法：
%wheel ALL=(ALL) ALL在%wheel ALL=(ALL) NOPASSWD上方 → 实际生效的是带密码那条 - 检查顺序：用
sudo -l -U username查看该用户最终匹配到的规则（注意不是sudo -l） - 避免混用别名：如果定义了
Cmnd_Alias但没把systemctl加进去，单独给%wheel的 NOPASSWD 也不管用
sudoers 修改后不生效的典型排查路径
改完 /etc/sudoers 最容易忽略的是语法校验和缓存机制——sudo 不会自动 reload，也不会告诉你哪行写错了，只会静默失败。
性能 / 兼容性影响：错误的 sudoers 会导致所有 sudo 命令变慢（超时等待），甚至阻塞 SSH 登录（如果 PAM 集成了 sudo）。
- 必须用
sudo visudo编辑，它会在保存前执行visudo -c校验语法 - 手动校验命令：
sudo visudo -c，看到sudoers file parsed OK才算安全 - 清除 sudo 时间戳缓存：
sudo -k，否则旧的密码状态可能干扰测试 - 注意 SELinux：某些发行版（如 RHEL/CentOS）开启 SELinux 后，
/etc/sudoers的上下文不对也会导致规则不加载
真正麻烦的是规则叠加和隐式继承——比如用户既在 wheel 又在 docker 组，而两个组的 sudo 规则互相冲突，这时候 sudo -l -U username 的输出就是唯一可信依据。
