CentOS 7 不提供用户组权限分配策略机制，仅通过 chmod、chown/chgrp 和 usermod -aG 等底层操作手动实现；组本身无策略能力，权限判定依赖进程 UID/GID、文件权限位及用户是否属该组。
直接说结论：CentOS 7 本身不提供“用户组权限分配策略”这种抽象的、策略式配置机制——它只认具体的文件/目录权限（chmod）、归属（chown/chgrp）和用户组成员关系（usermod -aG）。所谓“策略”，其实是你通过组合这些底层操作手动实现的。
为什么不能像 SELinux 或 sudoers 那样配“组级策略”
在 Linux 的权限模型里，普通用户组（比如 developers）更像是一个“身份标记”，并不会天然附带执行能力，也不会自动生成访问规则。系统真正做权限判断时，看的其实就这几项：
• 进程运行时的有效 UID/GID
• 目标文件的 owner:group:other 三段权限位
• 用户是否属于该文件所属的组（也就是 groups 命令输出里有没有这个组名）
也正因为如此，“把 /var/log 的读写权限交给某个组”这件事，不能只停留在建组这一步，而是得手动完成下面这些设置：
• 把目标目录的属组改成该组（chgrp developers /var/log）
• 给组开启写权限（chmod g+rw /var/log）
• 确保所有相关用户都已经加入这个组（usermod -aG developers user1）
usermod -aG 是唯一安全添加组成员的方式
常见错误是漏掉 -a 参数：
• usermod -G devs alice → 覆盖全部附属组，alice 可能瞬间丢掉 sudo、wheel 等关键组
• usermod -aG devs alice → 正确：仅追加，不破坏已有组关系
其他要点：
• 修改后用户需重新登录（或 newgrp devs）才能生效组权限
• id alice 必须看到 devs 出现在 groups 列表里，才算成功
• 不要依赖 /etc/group 手动编辑 —— 容易格式错、锁文件、引发 usermod 冲突
目录级权限必须配合 umask 和 setgid 才能“持续生效”
就算把 /opt/project 设成 drwxrws---（也就是开启了 g+s，同时给组写权限），也别急着以为万事大吉。新建文件默认还是有可能不落在这个组里。原因很直接：
• 普通用户创建文件时，新文件的属组通常取的是用户主组（id -gn 的输出结果），并不是目录本身的所属组
解决办法也得一步步来：
• 先执行 chmod g+s /opt/project（把 setgid 位打开）
• 再确认用户主组就是目标组（例如 usermod -g devs alice），或者让用户通过 newgrp devs 临时切换主组
• 检查系统里的 /etc/login.defs，看看 UMASK 是否设为 002（这样才能默认保留组写权限）
• 还要注意一点：umask 002 对 root 不生效（root 默认是 umask 022），这部分需要单独处理
真正容易被忽略的是 setgid 目录与用户主组的耦合关系：哪怕你把用户加进了 devs 组，只要他当前主组不是 devs，且目录没开 g+s，他在里面新建的文件就依然归他自己主组管——权限策略就断在第一环。
