直接用 id 命令判定容器内账号真实特权：id -u 为 0 表示 root；id -g/-ng 列出所有组 id 及名称，含 docker 或 systemd-journal 等关键组可揭示逃逸能力；id -ru 与 id -u 不一致则存在 setuid 提权风险。
直接用 id 命令就能快速判定容器内运行账号的真实特权，关键不是“看用户名”，而是看 UID、GID 和所属组的数字与名称组合——这些才是内核真正校验权限的依据。
查 UID 和主 GID，确认基础身份层级
在容器内执行：
- id -u：输出纯数字 UID。若为 0，说明是 root（最高特权）；非 0（如 1001）则为普通用户，需进一步看组权限
- id -g：输出主组 GID。它决定新创建文件的默认属组，也反映服务配置中常指定的 Group=xxx 字段是否匹配
- id -un 和 id -gn：分别显示当前用户和主组的名称（如 www-data、nogroup），便于对照 Dockerfile 或启动脚本中的用户声明
重点看 -G 和 -nG，识别实际可访问的资源范围
微服务常依赖特定系统组才能访问日志、设备、socket 或挂载目录：
- id -G：列出所有组的数字 ID（如 1001 27 109）。其中 27 是 sudo，109 可能是 docker 或 systemd-journal 组
- id -nG：显示对应组名（如 www-data sudo systemd-journal）。若含 systemd-journal，说明可读 journalctl 日志；含 docker 则可能调用宿主机 Docker socket
- 注意：即使 Dockerfile 写了
USER www-data，若该用户被加入多个附加组，特权就远超表面身份
用 -r 验证是否被 setuid 或 su 欺骗
某些容器镜像或启动方式会通过 setuid 程序切换有效用户，但真实 UID 才代表进程原始身份：
- id -ru 和 id -u 对比：若两者不一致（如 -ru=1001，-u=0），说明当前 shell 是由其他用户（如 root）以 setuid 方式启动的，存在提权风险点
- id -rg 同理，可发现主组是否被临时覆盖
结合容器上下文交叉验证
单看 id 不够，需联动判断：
- 对比宿主机上同 UID 的用户：cat /etc/passwd | awk -F: '$3==1001 {print}'，确认该 UID 在宿主机是否对应高危账户
- 检查挂载目录权限：ls -ld /host/path，再用 id -u 和 id -G 看当前 UID/GID 是否匹配目录的 owner/group
- 若服务需访问 /var/run/docker.sock，必须确保 id -nG 输出包含 docker 组，否则权限拒绝不是配置问题，而是身份缺失
