ACL是在POSIX基础之上叠加的精细化权限控制层，突破单用户单组限制，支持为任意数量用户/组单独授权，通过default ACL实现新建文件自动继承，并由mask字段统一管控非所有者权限上限。
ACL 本身不是用来“打破”三位一体限制的工具，而是**在保留 POSIX 基础上扩展权限表达能力的机制**。它不替代 u/g/o，而是在其之上叠加更细粒度的控制层，从而绕开“只能设三类人”的硬约束。
ACL 如何突破 u/g/o 的静态边界
传统权限中，“组”是唯一可复用的中间层，但一个文件只能属于一个 group，无法同时赋予 dev_group 写、qa_group 读、alice 完全控制——这正是死结所在。ACL 的解法是：在原有 owner/group/other 之外，**显式追加任意数量的 user 或 group 条目**。
-
允许为特定用户单独授权：比如
setfacl -m u:alice:rwx project/，无需把 alice 加入 project 组，也不影响其他用户 -
支持多个组并行授权：
setfacl -m g:dev_group:rw-,g:qa_group:r-x project/，两个组互不干扰，各得所需 -
可撤销某用户权限而不动全局：
setfacl -x u:bob project/，比从组里踢人更精准、无副作用
系统集成时 ACL 的典型落地方式
真正发挥 ACL 价值，靠的是与身份和目录系统联动，而非孤立使用命令行。
-
对接 LDAP/AD 组同步：当企业 AD 中新增 qa_group 成员，HDFS 或 NFS 服务自动识别该组，并按预设 ACL 规则应用到目标目录（如
default:g:qa_group:r-x） - 与 RBAC 平台协同分工：RBAC 管角色生命周期（谁该有哪个角色），ACL 管资源侧具体放行（这个角色在该路径下能做什么）。例如 Zilliz Cloud 将企业 SCIM 同步的部门组映射为平台角色，再由 ACL 引擎将角色绑定到集群/项目级资源
- 配合 Kerberos 实现可信上下文：用户通过 Kerberos 登录后，HDFS 服务拿到其 principal 和所属 groups，再查 ACL 列表匹配 user:: / group:: / named user / named group 四类条目，完成最终鉴权
注意 ACL 的适用边界
它强在“单资源多主体”，弱在“跨资源批量治理”。比如要给 200 个新项目统一设置 dev_group:rw-，仍需脚本遍历或依赖默认 ACL（setfacl -d）；若涉及角色变更（如 dev_group 改名）、权限语义升级（如新增“导出”动作），ACL 本身无法自动传播——这时必须由上层 RBAC 或策略引擎驱动 ACL 更新。
换句话说，ACL 解决的是权限表达维度不足的问题，不是权限管理效率瓶颈的问题。它和 RBAC 不是对立关系，而是分层协作：RBAC 定义“谁是什么”，ACL 定义“在哪儿能干啥”。
