linux权限管理核心在于清晰边界、可追溯操作与审计合规：su需用su -确保环境完整，sudo必须通过visudo配置，遵循最小权限、白名单、日志记录及定期审查原则。
Linux 用户身份切换不是简单输个密码的事，核心在于权限边界是否清晰、操作是否可追溯、配置是否经得起审计。su 和 sudo 表面功能相似，但设计哲学完全不同：su 是“交出钥匙”，sudo 是“授权开门”。维护严谨性，关键在用对工具、配准规则、守住最小权限。
su 切换必须区分环境加载方式
不带 - 的 su username 只切换 UID/GID，保留原用户的 HOME、PATH、MAIL 等变量，容易导致命令找不到、配置读错、日志写入异常。例如执行 su root 后运行 systemctl，可能因 PATH 未更新而调用旧版二进制文件。
真正需要完整 root 环境时，必须用 su - 或 su -l。它会加载 /root/.bashrc、/root/.profile，重置所有环境变量，确保行为与直接登录 root 一致。日常运维中，应默认采用带 - 的形式，避免环境残留引发的隐蔽问题。
sudo 权限必须通过 visudo 配置，禁止直接编辑 sudoers
/etc/sudoers 是权限策略的唯一权威来源，语法极其严格。手动用 vim 或 nano 编辑极易引入格式错误（如多余空格、缺少换行、括号不匹配），导致整个 sudo 失效，甚至锁死系统管理通道。
正确做法是始终使用 visudo 命令打开配置文件。它会在保存前自动语法校验，出错即提示并阻止写入。配置新增用户权限时，推荐按角色分组管理，例如：
- 新建专用组
adminops：groupadd adminops - 将用户加入组：
usermod -aG adminops alice - 在
/etc/sudoers中添加一行：%adminops ALL=(ALL) NOPASSWD: /usr/bin/systemctl start nginx, /usr/bin/journalctl -u nginx
这样既避免给用户全权，又明确限定可执行的具体命令及其参数范围。
sudoers 规则要遵循最小权限与显式白名单原则
严禁使用 ALL=(ALL) ALL 这类宽泛授权。真实生产环境中，应逐条声明允许的操作。例如运维需重启服务，只放行 /bin/systemctl restart httpd，而非整个 systemctl；需查看日志，只允许 /usr/bin/journalctl -u httpd --no-pager -n 50，禁用 -o json 或 --all 等高风险选项。
可利用 Command_Alias 提升可读性与复用性：
Command_Alias HTTP_CMD = /bin/systemctl start httpd, /bin/systemctl stop httpd, /bin/systemctl restart httpd<br>%http_admins ALL=(root) NOPASSWD: HTTP_CMD
同时启用日志记录：Defaults logfile="/var/log/sudo.log"，确保每次 sudo 执行都留下完整时间、用户、主机、命令痕迹，满足安全审计要求。
定期审查与失效机制不可缺失
权限不是一次配置终身有效。建议每月执行一次 sudoers 审查：
- 运行
sudo -l -U username核对实际生效权限是否与预期一致 - 检查
/var/log/sudo.log中是否存在异常高频调用或陌生命令 - 对已离职或转岗人员，立即从相关组中移除：
gpasswd -d bob adminops - 对临时提权需求，使用
sudo -i -u deploy /bin/bash并设定超时退出，避免长期保持高权限 shell
没有审查的权限配置，等于把门钥匙挂在门把手上——看似上了锁，实则形同虚设。
