答案是su和sudo本质不同：su是切换身份，需目标密码，操作不可追溯；sudo是委托权限，需自身密码，支持最小化、可审计的精细授权。现代安全实践禁用su切root，全面采用sudo配置。
Linux 用户权限提升不是靠“猜密码”或“硬闯”，而是通过明确的机制设计来实现可控、可审计的提权。核心就两个命令：su 和 sudo，但它们的设计哲学、安全边界和配置方式完全不同。真正安全的系统，几乎从不依赖 su 切换到 root，而是用 sudo 做最小化、可追溯的授权。
su：切换身份，简单但危险
su（Substitute User）本质是“变成另一个人”。执行 su - 时，系统会验证目标用户的密码（比如 root 密码），成功后启动一个新 shell，RUID 和 EUID 都变为目标用户，环境变量、家目录、shell 配置也全部继承。这意味着你获得的是目标用户的完整上下文——包括所有权限、所有文件访问能力、所有能执行的命令。
问题在于：一旦知道 root 密码，任何人都能完全接管系统；所有操作日志里只显示 “root 执行了 XXX”，无法定位具体是谁干的；也没有命令级限制，只能“全有”或“全无”。
实际建议：
- 禁用 root 的远程 SSH 登录（修改 /etc/ssh/sshd_config 中的 PermitRootLogin no）
- 避免在生产环境用 su - 切到 root；如必须临时使用，优先用 su -c 'command' 执行单条命令，而非进入交互式 shell
- 若需保留 su 功能，可通过 PAM 模块（如 pam_wheel.so）限制只有 wheel 组成员才能 su，再严格控制该组成员
sudo：委托权限，精细且可审计
sudo 不是“变成 root”，而是“以 root 身份运行某条命令”。它依赖 setuid 机制：/usr/bin/sudo 文件属主为 root 且设置了 s 位（-rwsr-xr-x），所以任何用户执行它时，进程以 root 权限运行，再由它自己根据规则决定是否放行后续命令。
关键优势在于三重控制：谁（user/group）、在哪台机器（host）、能做什么（command path）。所有行为写入 /var/log/auth.log 或 /var/log/secure，精确到命令参数和执行时间。
配置要点：
- 永远用 visudo 编辑 /etc/sudoers，它会语法检查，防止锁死整个系统
- 基本格式：user host=(runas) tags: command，例如 alice ALL=(root) /bin/systemctl restart nginx
- 免密需显式声明 NOPASSWD:，如 deploy ALL=(root) NOPASSWD: /bin/systemctl reload nginx
- 禁止通配符滥用，/usr/bin/* 比 /usr/bin/systemctl 危险得多；用 ! 显式排除高危命令，如 Cmnd_Alias SAFE = /bin/systemctl, !/bin/systemctl reboot
权限配置实战：从入门到防坑
新手常犯的错不是不会写，而是忽略上下文细节。比如：
- PATH 陷阱：sudo 默认不继承用户 PATH，sudo apt update 可能失败，因为 /usr/bin 不在默认安全路径里。解决方法是用 sudo env "PATH=$PATH" apt update 或在 sudoers 中加 Defaults env_keep += "PATH"
- 环境变量丢失：执行 sudo -u www-data python3 script.py 时，脚本可能因找不到自定义模块报错。加 -E 选项保留环境：sudo -E -u www-data python3 script.py
- shell 启动文件不加载：直接 sudo -u appuser command 不读 ~/.bashrc；要用 sudo -i -u appuser -c 'command' 模拟登录态
- 时间戳缓存误导：sudo 默认 15 分钟内免密，但不同终端独立计时。调试时可用 sudo -k 清除当前终端缓存，避免误判权限是否生效
安全底线：三条不可妥协的原则
无论团队规模大小，以下原则必须落地：
- root 密码不共享：su root 的密码只用于应急恢复介质，日常运维彻底弃用
- 最小权限交付：给开发人员重启服务的权限，绝不给整个 systemctl；给 DBA 执行 pg_dump 的权限，不给 /bin/bash
- 所有提权可回溯：确保 rsyslog 正常采集 auth 日志，定期抽查 sudo -l -U username 输出与实际配置是否一致
