核心是将“谁可以做什么”转化为“哪个组能访问哪些资源”，再把用户归入对应组；通过认证层确认用户所属组、鉴权层校验请求组权限、资源层显式标注组白名单三层协同实现，结合OS层组权限强化文件访问控制。
多用户系统实现基于组权限的软件资源访问控制，核心是把“谁可以做什么”转化为“哪个组能访问哪些资源”，再把用户归入对应组。这种方式比逐个配置用户权限更清晰、更易维护。
分组设计与资源绑定
先按职能或使用场景划分逻辑组，比如 dev（开发）、qa（测试）、ops（运维）。每个组不直接关联具体人，而是绑定到软件资源上——例如，只有 ops 组能调用服务重启接口，dev 组只能提交代码构建任务。资源可以是 API 路由、CLI 命令、Web 页面模块或后台服务端点。关键在于，权限策略写在资源侧，而不是用户侧。
组权限落地的三层支撑
真正让组权限生效，需要三个层面协同：
-
认证层：用户登录后必须明确归属至少一个有效组（如通过 JWT 的
groups字段或数据库查user_groups关系表） - 鉴权层：中间件或路由守卫检查当前请求是否属于目标资源允许的组列表，不匹配则拒绝（HTTP 403）
- 资源层：每个可操作对象（如某个模型训练任务、某类日志下载链接）需显式标注其所属组白名单，支持单组或多组
避免常见失效点
组权限容易“设了却不管用”，往往卡在这些细节：
- 用户加入新组后未重新登录或刷新会话，导致组信息未加载（Linux 下可用
newgrp临时切换，Web 系统需重发 token） - 资源默认开放给“所有组”或留空组限制，相当于没设防
- 权限检查只做一次（如仅校验登录态），后续子操作（如回调、异步任务）未继承原始组上下文
- 命令行工具未读取用户组信息，仍依赖文件系统权限，需额外集成
getent group或调用系统 API
结合文件系统强化控制
对依赖本地文件或目录的软件（如日志导出、模型缓存读写），组权限要延伸到 OS 层：
- 将软件运行用户加入对应功能组（如
sudo usermod -aG ml-runner alice） - 把关键目录属组设为该功能组，并开启 setgid（
chmod g+s /var/lib/ml-jobs），确保新建文件自动继承组身份 - 目录权限至少保留
g+rx（组可读可进入），若需写入则加g+w
