UGO模型无法实现真正精细化授权，仅支持用户、组、其他三类主体和读、写、执行三种权限；精细化需依赖ACL，如为非属组用户单独授权、多组并行赋权或默认继承多组权限。
UGO 模型本身并不支持真正意义上的“精细化授权”——它只有三类主体（用户、组、其他）和三种权限（读、写、执行），天然存在颗粒度粗、灵活性低的限制。所谓“通过 UGO 实现精细化”，实际是指在 UGO 框架内，结合属主/属组调整、权限组合设计与合理协作流程，尽可能逼近精细控制的效果。真正的精细化（如单个非属主用户单独授权、多组并行赋权等）必须依赖 ACL。
明确属主与属组边界
UGO 的核心是身份归属，不是任意指定。精细化起点在于让文件/目录归属于最合适的用户和主组：
- 协作项目目录应由项目负责人创建，并将属组设为项目组（如 chgrp project-team shared/），再赋予属组读写执行权限（chmod 775 shared/）
- 敏感配置文件属主设为服务运行用户（如 nginx），属组设为运维组，权限设为 640（属主读写、属组只读、其他人无权）
- 避免把所有文件属主设为 root，除非确需系统级管控；普通协作场景中，属主应是具体责任人
用权限位组合表达访问意图
UGO 权限数字或符号不是随意设置，而是对业务逻辑的编码：
- 750：属主全权、属组可读可执行（能进入目录、查看内容）、其他人完全隔离——适合团队共享脚本或部署目录
- 644：属主读写、属组和其他人只读——适用于文档、配置模板等只读分发场景
- 600：仅属主可读写——用于密钥、凭证等高度敏感文件
- 目录必须有 x 才能被 cd 进入或 ls 列出，所以协作目录不能设为 664（缺 x），而应是 775 或 755
配合 chown/chgrp 动态调整归属
当人员变动或职责转移时，UGO 的“精细化”体现在及时更新归属关系，而非硬编码权限：
- 成员退出项目组，将其从属组中移除（gpasswd -d user project-team），无需修改每个文件权限
- 新负责人接手，直接 chown newlead:project-team dir/，再按需微调权限（如 chmod g+s dir/ 确保新建文件继承属组）
- 避免用 chmod o+rwx 开放权限来“临时解决访问问题”，这会破坏最小权限原则
识别 UGO 的固有局限并适时升级
遇到以下情况，说明 UGO 已无法满足需求，应切换到 ACL：
- 需要给某位临时协作者（不在属组中）单独开通读写权限
- 同一目录下，部分子目录需对 A 组开放、另一些对 B 组开放
- 希望新创建的文件自动继承多个不同组的权限（UGO 只能继承一个属组）
- 审计要求记录“谁被额外授权”，而 UGO 无法体现这类显式授权行为
