linux用户群组管理的核心目标是用最少的权限变更实现最清晰的职责隔离与协作支持，关键在于按角色建组、主组用于文件归属、附加组用于授权，并配合sgid与acl保障协作一致性及定期清理无效组。
按角色建组，而非按人建组
组的本质是权限容器，不是人员名单。应围绕系统功能或业务职责定义组名，例如：
• webdev：有代码推送和测试目录写入权限
• dbbackup：仅能执行备份脚本、读取备份目录
• logviewer：只读访问/var/log下的指定子目录
避免使用模糊名称如“team1”或“users”，也不要把运维、开发、测试混在一个组里。一个用户可属于多个组，但每个组的权限必须单一、明确、可审计。
主组用于归属，附加组用于授权
每个用户有且只有一个主组（Primary Group），它决定新创建文件的默认所属组。因此：
• 主组应设为个人专属组（如alice），避免多人共用导致文件归属混乱
• 所有共享权限都通过附加组（Supplementary Group）赋予，例如：sudo usermod -aG webdev,logviewer alice
这样既保证 alice 创建的文件默认归 alice 组（安全），又让她能访问 webdev 和 logviewer 的受控资源（灵活）。
目录权限配合 SGID 与 ACL 实现协作一致性
多人协作目录（如 /srv/project）不能只靠 chmod 775 解决问题——新文件仍可能继承错误的组。正确做法是：
• 设置目录属组为协作组：sudo chown :project_team /srv/project
• 启用 SGID 位：sudo chmod g+s /srv/project → 确保新创建文件自动继承 project_team 组
• 若需更细粒度控制（如某人只读、某人可删），补充 ACL：sudo setfacl -m u:bob:rx /srv/projectsudo setfacl -m u:charlie:rwx /srv/project
ACL 不替代传统权限，而是叠加增强，适合跨组精细授权。
定期清理无效组与成员关系
组长期不维护会成为权限漏洞源头。建议：
• 每季度运行 getent group | awk -F: '$4 == "" {print $1}' 查无成员组
• 对比 find / -type d -group obsolete_group 2>/dev/null 确认是否仍有资源绑定
• 删除前先禁用（改组名为 obsolete_组名），观察两周日志有无报错
• 用户离职时，用 sudo usermod -G "" username 清空其附加组，再删账号
