最安全、最可逆的方式是将用户从sudo组（Ubuntu/Debian）或wheel组（RHEL系）中移除，不删账户、不改密码、不触碰/etc/sudoers主文件；验证需执行sudo -n true测试并确认groups输出已更新。
直接禁用普通用户的 sudo 权限，最安全、最可逆的方式是将其从授权组中移除——不是删用户、不改密码、不碰 /etc/sudoers 主文件，只动组成员关系。
怎么判断用户是通过哪个组获得sudo权限
不同发行版默认启用的授权组不同，不能一概而论：
- Ubuntu/Debian 系：看是否在
sudo组里（groups $USER输出含sudo） - RHEL/CentOS/Rocky/AlmaLinux：看是否在
wheel组里（getent group wheel | grep $USER） - 银河麒麟 V10：默认走
sudo组白名单，但还叠加了kysec框架拦截，需额外检查
执行 sudo -l -U $USER 可直观看到当前生效的规则来源（比如来自 %sudo 还是 /etc/sudoers.d/webadmin），比盲猜更可靠。
从组中移除用户（推荐首选）
这是最小侵入、最易回滚的操作。注意命令差异：
- Ubuntu/Debian：
sudo deluser $USER sudo - 通用 Linux（含 RHEL 系）：
sudo gpasswd -d $USER sudo或sudo gpasswd -d $USER wheel - 移除后必须重新登录，否则
groups仍显示旧结果，sudo也暂不失效
别用 usermod -G 全量重置组列表——它会清掉用户所有其他组（如 docker、plugdev），引发意外权限丢失。
为什么改了组还不生效？常见卡点
移组后 sudo -l 仍显示权限，大概率踩了以下坑：
-
/etc/sudoers或/etc/sudoers.d/下有直写该用户的规则（如$USER ALL=(ALL) ALL），组移除无效 -
/etc/sudoers文件末尾缺#includedir /etc/sudoers.d，导致子配置未加载，但你误以为没生效 - 银河麒麟等定制系统启用了
kysec框架，即使不在sudo组，kysec的 enforcing 模式仍可能放行或拦截，需运行sudo kysec status确认 -
/usr/bin/sudo被手动加过setuid位（-rwsr-xr-x），且权限未被重置，二进制本身还能提权
验证是否真禁用：用目标用户执行 sudo -n true 2>/dev/null && echo ok || echo blocked，避免交互干扰。
彻底禁用（仅限高安全场景）
如果连 sudo 命令本身都不能存在（例如等保三级要求），才考虑组合操作：
- 先移出授权组
- 再运行
sudo chmod 0755 /usr/bin/sudo清掉setuid位（变成-rwxr-xr-x） - 最后确认
ls -l /usr/bin/sudo输出不含s，且sudo -V仍能运行但提权失败
注意：卸载 sudo 包或删二进制文件属于破坏性操作，会导致依赖 sudo 的运维脚本、Ansible 任务、桌面环境策略全部中断，不建议常规使用。
