centos 7 不提供用户组权限分配策略机制，仅通过 chmod、chown/chgrp 和 usermod -ag 等底层操作手动实现；组本身无策略能力，权限判定依赖进程 uid/gid、文件权限位及用户是否属该组。
直接说结论：CentOS 7 本身不提供“用户组权限分配策略”这种抽象的、策略式配置机制——它只认具体的文件/目录权限（chmod）、归属（chown/chgrp）和用户组成员关系（usermod -aG）。所谓“策略”，其实是你通过组合这些底层操作手动实现的。
为什么不能像 SELinux 或 sudoers 那样配“组级策略”
普通用户组（比如 developers）在 Linux 权限模型里只是个“标签”，它本身不携带任何执行能力或访问规则。系统判断权限时，只看：
• 进程运行时的有效 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，他在里面新建的文件就依然归他自己主组管——权限策略就断在第一环。
