最可靠的方法是使用 groups 命令或 id -gn，它们读取内核维护的当前会话组列表；usermod -ag 才能追加组，否则 -g 会覆盖；chgrp 后需确保目录有执行位、文件有对应组权限，且 umask 或 setgid 配合；sudo 权限需结合 groups、sudo -l 和 /etc/sudoers 中组策略综合判断。
如何确认当前用户属于哪些组
直接查 /etc/group 太慢，也容易漏掉临时组（比如通过 newgrp 切换的）。最可靠的是用 groups 命令，它读取的是内核维护的当前会话组列表：
-
groups显示当前 shell 会话中生效的全部组（含主组和附加组） -
id -Gn效果相同，但更明确——-G取所有组 ID，-n转成名字 - 注意：
usermod -aG添加组后，必须重新登录或新开 shell 才生效；只改/etc/group文件不触发内核组缓存更新
给用户加组却没权限？检查 adduser 和 usermod 的关键区别
很多人用 usermod -G groupname username 加组，结果发现旧组全没了——因为没加 -a（append）标志。这是最常踩的坑：
-
usermod -G docker alice→ 把alice的附加组**重置为仅 docker**，原属的sudo、plugdev全丢 - 正确写法是
usermod -aG docker alice，-a必须和-G同时出现才表示追加 -
adduser默认交互式添加，不会覆盖已有组，但脚本里少用；批量操作一律优先选usermod -aG
为什么文件属组改了，用户还是不能读？看 umask 和目录执行位
组权限不是改完 chgrp 就自动生效的。两个硬性前提常被忽略：
- 目标文件/目录必须有对应组的读（
r）或执行（x）权限，否则chgrp只是“名分”到位，实际进不去 - 新建文件的默认组权限受
umask控制：如果umask是0022，则新文件组权限是644（即rw-r--r--），组用户只能读不能写；要支持组写，需设umask 0002或对目录设setgid位（chmod g+s dirname） - 目录必须有
x权限，组成员才能cd进入或ls列出内容——这点比文件更关键
sudo 组权限失控？别只盯 /etc/sudoers，先查 sudo -l
用户报“没有 sudo 权限”，但 usermod -aG sudo alice 已执行——大概率是发行版策略差异导致的：
- Debian/Ubuntu 默认允许
%sudo组执行所有命令；CentOS/RHEL 默认是%wheel组，且/etc/sudoers里%wheel行默认被注释 - 用
sudo -l -U alice直接查该用户实际能跑什么，比翻配置文件快得多 - 如果提示
user not allowed to run sudo，先确认alice是否在正确的组（groups alice），再检查/etc/sudoers中对应组是否启用且未被!sudo显式禁止
组权限生效依赖会话刷新、目录执行位、umask 设置、发行版默认策略四者齐备，缺一不可。最容易被跳过的就是新开 shell 和检查 sudo -l 输出。
