Linux ACL 是叠加在传统权限之上的精细控制层，不替代基础权限；mask 是非属主、非other条目的最大有效权限上限，default ACL 仅对新文件/目录生效且仅目录可设。
Linux ACL 不会与标准权限冲突，而是叠加在其之上；所谓“冲突”，其实是 mask 限制、继承逻辑误用或路径权限缺失导致的权限未生效。只要理解 ACL 的运行机制，就能避免绝大多数问题。
理解 mask 的实际作用
mask 不是传统意义上的掩码，而是除 owner 和 other 外所有 ACL 条目（user:、group:、named group）的**最大有效权限上限**。即使你给 user:alice 设置了 rwx，若 mask 是 r--，alice 实际只能读。
- setfacl -m 命令通常会自动重算 mask，但手动调整后可能滞后
- 查看 mask 状态：getfacl file.txt 中找 mask:: 行
- 强制更新 mask：setfacl -m m::rwx dir/（例如让所有扩展权限可写）
- 目录下文件的 mask 默认继承自父目录，但不会自动同步更新
确保路径可访问：x 权限是前提
ACL 控制的是“能做什么”，但前提是用户能到达目标位置。对目录而言，缺少 x 权限等于关着门——进不去，就谈不上读写其中内容。
- 用户要进入 /shared/docs，必须对 /shared 和 /shared/docs 都有 x 权限
- 要列出目录内容，还需 r 权限；要创建/删除文件，还需 w 权限
- ACL 可以单独给某用户加 x，但若其所属组或 other 没有 x，仍无法 cd 进入
- 检查方式：su - alice -c "ls /shared/docs"，比单纯看 getfacl 更直观
默认 ACL 只影响新创建项
设置 setfacl -m d:u:bob:rwx project/ 后，project/ 下新建的文件自动获得 bob:rwx，但已有文件不受影响——这是常见误判源头。
- 已有子项需显式递归设置：setfacl -Rm u:bob:rwx project/
- 想统一恢复默认规则：先 setfacl -b project/ 清空，再设默认 ACL
- 注意：默认 ACL 本身不赋予权限，只定义“未来谁有什么”
- umask 仍起作用：即使默认 ACL 设为 rwx，若 umask 是 0027，新文件实际可能是 rw-r-----
验证真实身份而非用户名
ACL 匹配基于 UID/GID，不是用户名字符串。重名用户、NIS/LDAP 环境或 UID 冲突都可能导致规则失效。
- 查用户 UID：id -u alice
- 查文件 ACL 中的 UID 映射：getfacl file.txt | grep "user:alice"
- 若输出是 user:1024:r-x，而当前 alice 的 UID 是 1025，则规则不生效
- 跨主机迁移 ACL 时，建议用 UID 而非用户名导出：getfacl -n file.txt
最佳实践建议
ACL 的价值在于“轻量叠加”，不是重构整个权限体系。用得好，可以避开 chmod 777、频繁改组、建冗余组等高风险操作。
- 优先用标准权限定基调（如属组 + rwx），ACL 只补例外（如临时加一个协作者）
- 目录务必设默认 ACL（d:前缀），否则协作中每次新建文件都要手动授权
- 定期备份 ACL：getfacl -R /path > acl-backup-$(date +%F).acl
- 清理历史条目：setfacl -x u:olduser file 或 setfacl -b file（慎用）
- 生产环境首次启用前，先在测试分区验证挂载选项和 mask 行为
