应先用id命令查看用户UID、GID及所有附加组，如id显示groups含sudo或wheel组，仅说明理论能力；实际sudo权限须以sudo -l或sudo -n true验证，因组存在不等于sudoers中已授权，且sudo -l报“not allowed”表明配置完全缺失而非被禁用。
直接看用户身份和组归属用 id
权限起点不是“能不能执行某个命令”，而是“你是谁、属于哪些组”。id 一次性输出 UID、GID 和所有附加组，最接近真实权限边界。
-
id（不带参数）显示当前用户完整身份，比如uid=1001(dev) gid=1001(dev) groups=1001(dev),27(sudo),115(docker)—— 这说明该用户理论上具备 sudo 和 docker 组的系统能力 -
id -n -G只输出组名，适合脚本判断：id -n -G | grep -q '\bsudo\b'比groups | grep -q sudo更可靠（避免匹配到类似sudoers的组名） -
id username查他人权限无需切换账户，但需有读取/etc/passwd权限（普通用户默认有）
查 sudo 实际可用权限别信 groups，要用 sudo -l 或 sudo -n true
用户在 sudo 组里 ≠ 能用 sudo。很多系统默认启用 %sudo ALL=(ALL:ALL) ALL，但管理员可能已删掉、注释或收紧成窄权限条目。
-
sudo -l显示空或报User username is not allowed to run sudo on hostname，说明/etc/sudoers或/etc/sudoers.d/中**完全没有显式授权条目**，不是“被禁”，是“没配” -
sudo -l -U username需调用者自己有 sudo 权限，非 root 用户无法用它查别人 - 脚本里静默判断必须用
sudo -n true：返回码 0 表示有权限（且免密或缓存有效），返回 1 表示无权限或需密码但-n拒绝交互；sudo -v会卡住等密码输入，sudo -l输出含敏感路径可能被审计拦截
文件级权限得看 ls -l 和实际访问行为
组成员关系只是基础，真正能否读写某个文件，取决于该文件的 owner/group/other 权限设置，以及是否启用 ACL。
-
ls -l /path/to/file看十字符权限串，如-rw-r-----：第 2–4 位是 owner 权限，5–7 是 group，8–10 是 others；当前用户若为 owner，或属于该文件所属组且 group 位有 r/w/x，才可能操作 -
ls -ld /path/to/dir查目录权限，注意目录的x位决定能否cd进入或ls列出内容（哪怕有 r 权限，缺 x 就进不去） - ACL（访问控制列表）会覆盖传统权限，用
getfacl /path查看；setfacl设置的规则优先级高于组权限，容易忽略
登录上下文影响权限表现，who 和 who am i 很关键
权限不是静态的。su/sudo 切换后，id 显示的是新用户身份，但某些环境变量或会话限制（如 requiretty）可能让 sudo 失效，而你未必意识到当前 shell 并非原始登录会话。
-
who am i（注意空格）只显示当前 shell 对应的登录记录，比whoami更准——后者只返回用户名，不反映登录方式（SSH？console？su 切换？） -
who -u加上空闲时间和 PID，能帮你识别是否因长时间未操作导致会话降权，或某个后台进程占用了特权上下文 - 执行命令报 “Permission denied” 时，先
id确认组，再who am i确认当前会话来源，最后ls -l查目标对象权限，三步闭环比瞎猜快得多
真正麻烦的不是查不到权限，是查到“有”却执行失败——比如 sudo -l 显示允许 /usr/bin/systemctl restart nginx，但你输成 sudo systemctl restart nginx，因为 systemctl 是 shell 的 PATH 查找结果，而 sudoers 里只白名单了绝对路径。这种路径不一致、通配符静态匹配、策略拦截（requiretty）、甚至 hostname 不匹配 Host_Alias 的问题，都藏在表层之下。
