linux acl是传统ugo权限的补充而非替代，用于为任意用户或组单独赋权，支持默认acl自动继承，权限按属主→acl用户→属组→acl组→其他人顺序匹配，并受mask限制。
Linux ACL（Access Control List）不是对传统ugo权限的替代，而是补充。它解决的是“特定人需要特定权限，但又不能改变原有用户组结构或放宽其他人权限”这类真实场景。用好ACL，关键在理解规则逻辑、掌握核心命令、避开常见陷阱。
ACL 的核心价值与适用场景
传统ugo权限只有三类对象：所有者、所属组、其他人。一旦需求超出这个框架——比如让张三读某文件，而李四写同一文件，且两人不在同一组；或者新员工入职后需立即获得某目录下部分子目录的访问权，但不希望他加入现有业务组——ACL就是最直接有效的方案。
- 为任意用户或组单独赋权，无需调整其主组或附加组成员关系
- 支持默认ACL（d:前缀），让新建文件/子目录自动继承指定权限
- 权限叠加生效：ACL规则与ugo权限共存，系统按“属主 → ACL用户 → 属组 → ACL组 → 其他人”顺序匹配
- 权限被mask限制：ACL中非属主、非other的条目实际生效权限 = 设置权限 & mask值；通常保持mask为rwx即可避免意外降权
常用操作命令与典型用法
所有操作均基于 setfacl 和 getfacl 两个命令，无需额外安装（主流发行版默认包含）。
-
查看当前ACL：
getfacl filename—— 输出中出现user:xxx:rwx或group:yyy:rw-即表示已启用ACL；文件权限末尾带+（如-rw-rw-r--+）是直观标志 -
给用户授权：
setfacl -m u:username:rw filename -
给组授权：
setfacl -m g:groupname:rwx dirname -
设置默认ACL（仅目录有效）：
setfacl -m d:u:username:rwx dirname—— 此后在该目录下新建的文件/子目录会自动拥有该用户的rwx权限 -
递归设置（含子项）：
setfacl -R -m u:username:r dirname -
删除某条ACL：
setfacl -x u:username filename -
清空所有扩展ACL：
setfacl -b filename—— 注意：ugo基础权限不受影响
实战中必须注意的细节
ACL看似简单，但几个关键点常被忽略，导致权限不生效或行为异常：
-
文件系统需支持ACL：ext4/xfs默认开启，但若挂载时未启用
acl选项（可通过mount | grep acl确认），需先执行mount -o remount,acl /；永久生效要改/etc/fstab -
mask不是可有可无的配角：当用
setfacl -m u:user:rwx后，若mask::r-x，则该用户实际只有rx权限。一般无需手动调mask，除非明确需要限制最大有效权限 -
不要混用chmod和setfacl修改同一对象：例如用
chmod 600会重置mask，可能使已有ACL失效；统一用setfacl管理更稳妥 -
默认ACL只影响新建项：对已存在文件/子目录无效，需配合
-R手动补设
一个完整工作流示例
假设项目目录/srv/project归属dev组，现需让运维人员ops仅能读取日志子目录/srv/project/logs，且该权限需对后续新建日志文件持续有效：
- 确保挂载支持ACL：
mount | grep " /srv " | grep acl，缺失则mount -o remount,acl /srv - 设置基础权限：
chmod 750 /srv/project/logs && chgrp dev /srv/project/logs - 授予
ops读权限：setfacl -m u:ops:r-x /srv/project/logs - 启用默认ACL，保障新建文件继承：
setfacl -m d:u:ops:r-x /srv/project/logs - 验证：
getfacl /srv/project/logs应显示user:ops:r-x和default:user:ops:r-x
