1. 组的基本概念与设计原则
1.1 组的作用与定位
在 Linux 系统中，组是将多个用户聚合在一起，用于统一权限管理的机制。通过把权限分配给组，可以简化对同一资源的访问控制，提升效率与一致性。
将用户加入一个或多个组后，系统就会将该组的权限应用到用户所访问的资源上。此处要强调最小权限原则，尽可能地只给组所需的访问能力。
1.2 GID 与命名规范
GID（组标识号）用于系统内部标识组，避免冲突时应使用未被占用的范围。命名规范应保持可读、与职责对齐，例如 devs、app、db。
在设计初期，建议规划好全局的组映射表，避免跨应用的重复分配。常见做法是把高危资源设定为受控组，低权限资源分配给通用组。
# 查看系统中已有的组及GID
getent group | awk -F: '{print $1\":\"$3}'
# 新建一个开发组，分配特定的GID（如1001）
groupadd -g 1001 devs2. 从创建组到日常管理
2.1 创建新组与命名规范
创建组时应遵循命名规范，确保组名能够反映职责范围。使用静态 GID 时有利于跨主机的权限一致性。
示例命令，如下演示如何创建一个开发组并指定 GID，后续可以复用在自动化配置中。
groupadd -g 1010 devs2.2 查看组信息与变更
系统提供多种方式查看组信息，例如通过 getent 或查询 /etc/group。确保变更日志可追踪。
常用操作包含查询、重命名、以及修改组的成员定义。
# 查找 devs 组信息
getent group devs
# 将组重命名为 development
groupmod -n development devs2.3 将用户加入组与成员管理
用户可以属于一个主组与若干附加组，附加组常用于权限继承。添加到组时推荐使用追加模式，避免覆盖原有组成员。
追加到组的示例，将 alice 添加到 devs 组，并确认所属组列表。
# 把 alice 加入 devs 附加组
usermod -aG devs alice
# 查看 alice 的所属组
id -nG alice3. 权限策略与高级配置
3.1 ACL 深入使用
ACL（访问控制列表）提供了对现有文件/目录权限的细粒度控制，超越传统的三组权限模型。通过 setfacl 可以为指定的组/用户设定额外权限。
核心要点是对共享目录、日志、构建产物等资源，使用组 ACL 让组内成员获得一致访问能力。
# 给开发组 devs 在 /shared 上授予 rwx 权限
setfacl -m g:devs:rwx /shared
# 为默认创建的新文件设置默认 ACL
setfacl -d -m g:devs:rwx /shared
# 查看当前 ACL
getfacl /shared3.2 sudoers 与策略化访问控制
结合 sudoers 文件，可以实现基于组的策略化执行权限，确保关键命令仅在授权组内执行而不暴露给普通用户。
示例策略，为 ops 组中的成员授予对特定服务的无密码执行权限，同时保留对其他命令的限制。
# 打开 sudoers 配置（需小心编辑）
# 在 visudo 中添加
%ops ALL=(ALL) NOPASSWD: /bin/systemctl restart httpd
4. 实操演练：从创建组到权限策略的完整实践
4.1 场景设计
场景聚焦于多团队协作环境，要求新建开发、运维、数据库三组，并为相关目录分配合理权限，确保最小权限与可追溯性。
目标是实现跨组协作高效、且不破坏原有安全策略。
4.2 实操步骤与要点
以下步骤覆盖从创建组、分配成员到应用 ACL 与 setgid 的完整流程。
# 1) 创建组
groupadd -g 1050 devs
groupadd -g 1051 ops
groupadd -g 1052 db# 2) 将用户加入组
usermod -aG devs alice
usermod -aG ops bob
usermod -aG dbcarol carol# 3) 设置共享目录及权限继承
mkdir -p /srv/projects/apps
chown root:devs /srv/projects/apps
chmod 2770 /srv/projects/apps# 4) 使用 ACL 细化权限
setfacl -m g:ops:r-x /srv/projects/apps
setfacl -d -m g:ops:r-x /srv/projects/apps# 5) 将部署用户加入开发组以获得必要权限
usermod -aG devs deploy