<p>whoami直接反映当前shell进程的EUID对应用户名，即“此刻以谁的权限运行”，不追溯登录历史或切换路径；例如alice→su - bob→su - root后执行whoami输出root，但显示root不等于拥有全部root权限，可能受HOME变量、SELinux、capabilities等限制。</p>

whoami 命令在多层级 su 提权后，直接反映的是当前 shell 进程的 有效用户 ID（EUID）对应的用户名，也就是“此刻真正拥有哪些权限”的身份，而不是你最初登录的是谁、或中间经过了几层切换。它不关心路径，只认内核给这个进程配的 EUID。

它怎么看多层 su 后的身份？

每次 su（尤其是 su - 或 su -l）都会创建一个新 shell，并把该 shell 进程的 EUID 设为目标用户。whoami 读取的就是这个 EUID，所以：

• 你从 alice → su - bob → su - root，最后运行 whoami，输出一定是 root
• 哪怕你执行了 su -c 'whoami' root，结果还是 root —— 因为 -c 启动的子进程 EUID 也是 root
• 它不会显示“alice 切到了 bob 再切到 root”，也不会回溯；它只回答“现在这个命令以谁的权限跑”

为什么有时候显示 root 却操作失败？

显示 root ≠ 拥有全部 root 权限。常见原因包括：

• HOME 环境变量未更新：比如用 su root（没加 -）后，HOME 还是 /home/alice，导致某些工具拒绝写入 /root
• SELinux 或 capabilities 限制：EUID=0 是基础，但访问 /root 还需 fsuid 或特定 capability（如 CAP_DAC_OVERRIDE）
• 文件系统挂载选项：如 root_squash 的 NFS 共享下，即使 EUID=0 也会被降权为 nobody

想确认“原始登录者”或“父进程是谁”怎么办？

whoami 不负责这些。你需要其他命令配合：

• 查最初登录用户：logname（读 utmp，最贴近“你是谁登进来的”）
• 查上一级进程的用户：id -un $PPID（看父 shell 是谁启动的）
• 查完整权限上下文：id（重点看 euid=0 和 egid=0 是否存在，再看 groups: 里有没有 wheel/sysadmin）
• 对比登录会话：who am i 显示的是 utmp 记录的登录行，通常停留在第一次 ssh 或 console 登录时的用户

脚本里做权限判断，怎么写才稳？

如果目标是“必须以 root 权限执行”，用 whoami 是可以的，但推荐更显式的写法：

• if [ "$(id -run)" != "root" ]; then echo "需要 root 权限"; exit 1; fi（id -run 明确查 EUID，语义比 whoami 更清晰）
• 避免只依赖 $(whoami) == "root" 就认为能操作 /etc/shadow —— 应补一句 test -r /etc/shadow || { echo "无法读取敏感文件"; exit 1; }
• 在 systemd service 或 cron 中慎用 whoami，优先用 id -un（它不依赖 utmp，兼容性更好）