为什么要分三个层次查
账号问题经常本质是组问题，而“属于哪些组”“当前有效组是什么”“某个组里有哪些人”是三件不同的事：id 给出 uid/gid 与全部附加组，groups 只列组名且主组排在最前，getent group 查某个组的成员列表（主组为该组的用户不会出现在这里）。另外进程在启动时固定身份，之后改组的变更对它无效。LDAP/AD 环境必须走 getent，直接读 /etc/group 会漏掉后端数据。
基本信息
| 适用平台 | Linux 与多数类 Unix（NSS/nsswitch） |
|---|---|
| 常用命令 | id、groups、getent group、getfacl |
| 数据来源 | /etc/group、/etc/passwd 以及 LDAP/AD/SSSD 后端 |
| 权限要求 | 普通用户即可查询组关系 |
| 核心概念 | 主组、附加组、会话内的有效组 |
典型使用场景
- 用户反馈“已经加进组了还是没权限”时的第一轮核查
- 接手他人维护的机器时确认账号身份全貌
- 审计 sudo、wheel、docker 等敏感组的成员
- 排查文件属组与预期不符，判断是组关系问题还是权限位问题
- AD/LDAP 接入后验证组映射是否按预期下发
查询与验证
查询与验证
id alice # uid/gid 与全部附加组，信息最完整
groups alice # 只看组名，主组排在最前
getent group dev # dev:x:1001:alice,bob；主组为 dev 的用户不在此列
getent group 1001 # 按 GID 反查组名
getent passwd alice # 第 4 字段是主组 GID
sudo -u alice -H groups # 以目标用户身份确认会话内的组
newgrp dev # 在当前 shell 临时把 dev 变成有效组（验证用）
ls -ld /data/dev && getfacl /data/dev # 目录属组与 ACL 是否符合预期三个层次的区别
| 命令 | 看到什么 | 典型误判 |
|---|---|---|
| id 用户名 | uid、主组 gid、全部附加组 | 把附加组当成已生效权限（还取决于会话是否刷新） |
| groups 用户名 | 组名列表，主组在前 | 以为主组也属于附加组（应看 getent passwd 第 4 字段） |
| getent group 组名 | 该组的成员列表 | 主组为该组的用户不出现，误判为漏人 |
| getfacl 路径 | ACL 条目（含具名用户与组） | 只看权限位忽略 ACL，出现“没权限却能读”的困惑 |
修改组关系后已登录的会话不会更新组身份：正在运行的服务与已开终端都沿用旧身份。排查前先确认会话新鲜度（新开终端、su - 或重启服务），否则会把结论带偏。
/etc/group 只代表本地文件后端。LDAP/AD/SSSD 环境下组关系要用 getent group 查询，它按 nsswitch 顺序合并各后端；直接读文件会得出与事实不符的结论。