usermod -ag 仅将用户添加到指定组，不自动赋予资源访问权限；真正生效需同时满足：目标资源属组设为该组，且权限位中group部分允许对应操作。
usermod -aG 不能直接改权限，只加组
修改用户组权限分配策略，本质不是“给用户加个组就完事”，而是让该组对特定资源（文件、目录、服务）拥有对应访问权。你执行 usermod -aG devops alice 只是把用户 alice 加入 devops 组，但 devops 组本身对 /var/www 或 /opt/app 这些路径有没有读写权限，完全没变。
常见错误现象：用户加入新组后立刻 ls /shared 报 Permission denied，以为命令没生效——其实是目标目录的属组没设成 devops，或者权限位没开 group 可读。
- 用户加入组后，当前 shell 会话不自动继承新组，需重新登录或运行
newgrp devops -
-aG中的-a很关键：漏掉它会清空用户所有附属组，只剩-G指定的那一个 - 组名必须已存在，
usermod不会自动创建组；先用groupadd devops
chown :groupname 和 chmod g+rwx 才真正赋予权限
组权限生效靠两件事：目标资源的属组（group ownership）设为此组，且权限位中 group 部分（中间三位）允许对应操作。缺一不可。
比如要让 devops 组能修改 /srv/project 下所有内容：
- 先确认目录属组：
ls -ld /srv/project→ 若显示drwxr-xr-x. 1 root root，说明属组是root，得先改：chown :devops /srv/project - 再开 group 写权限：
chmod g+rwX /srv/project（注意大写X：只对目录和已有执行位的文件加 x，更安全） - 递归设置子项：
chmod -R g+rwX /srv/project，但慎用-R，尤其对已有敏感文件
性能影响：chmod -R 在大目录下耗时明显，建议先 find /srv/project -type d -exec chmod g+rx {} \; 处理目录，再单独处理关键文件。
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
/etc/group 里改组成员不如用 usermod 稳定
别手动编辑 /etc/group 文件往某组后面加用户名，容易格式错（冒号分隔、末尾多空格）、权限校验失败，甚至导致 login 拒绝该用户。
正确做法始终用 usermod -aG groupname username。它的底层逻辑是调用系统库函数更新 NSS 数据源，兼容 LDAP/NIS 等扩展场景；而直接改文件只对本地文件模式有效，且跳过一致性检查。
-
getent group devops能验证组成员是否已生效（比cat /etc/group更可靠） - 如果用户已在多个组，
id username显示全部，但实际生效的是登录时确定的组列表，非动态刷新 - SELinux 启用时，光改传统权限不够，还需
semanage fcontext和restorecon同步上下文
sudo 权限不属于用户组权限范畴，得单独配
用户属于 wheel 组 ≠ 自动能 sudo。CentOS 7 默认注释掉了 %wheel ALL=(ALL) ALL 这行，必须手动取消注释，或明确给 devops 组授权：
- 编辑
/etc/sudoers用visudo（防止语法错误锁死 sudo） - 加一行：
%devops ALL=(ALL) NOPASSWD: /bin/systemctl start nginx, /usr/bin/rsync（限制命令更安全） - 测试：
sudo -l -U alice查看该用户实际可用的 sudo 命令
容易被忽略的点：组权限和 sudo 权限是两套独立机制，前者控制文件/进程访问，后者控制提权执行命令——混用或互替都会出问题。
