ACL是突破传统chmod三元权限限制的必要手段，适用于多用户异构协作、临时授权及审计精准控制等场景；setfacl通过-m、-d、-R等选项实现细粒度权限设置与默认继承，但需文件系统支持acl挂载选项且受mask和umask约束。
直接说结论：Linux 用户访问控制不能只靠 chmod 或 chown，必须分层组合——基础权限定边界、ACL 做细化、sudo 控制命令级操作、必要时叠加 SELinux 或防火墙。单一手段必然漏防。
什么时候该用 ACL 而不是 chmod？
当标准的“所有者/组/其他人”三元模型不够用时，比如：多个协作用户不属于同一组、某临时成员需临时读写但不该进主组、审计要求精确记录某人对某目录的权限——这时 setfacl 是唯一合理选择。
-
setfacl -m u:alice:rwX /project比把 alice 加进 devgroup 更安全，避免她意外获得其他组内文件权限 - 默认 ACL（
setfacl -d）只影响新创建项，已有文件不受影响，别误以为设了就全局生效 - 注意大写
X：它只在目录或已有执行位的文件上加 x，避免给普通文本文件误加执行权限 - ACL 权限优先级高于传统权限，但受
umask限制；若用户umask是 022，新建文件即使设了u:alice:rwX，也可能因掩码过滤掉写位
sudo 权限配置最容易踩的坑
90% 的 sudo 配置错误源于没理解 visudo 中的语法细节和执行上下文。
- 不要手写
/etc/sudoers，必须用visudo—— 它会语法检查，写错直接锁死 root 权限 -
username ALL=(ALL) /bin/systemctl restart nginx允许重启 nginx，但不等于允许改配置；若想连 reload 配置一起放行，得显式加/bin/systemctl reload nginx - 别滥用
NOPASSWD：生产环境至少保留密码二次确认，尤其涉及rm、dd、mount类高危命令 - 组授权写成
%webadmin ALL=(ALL) /usr/bin/nginx，但实际 nginx 启动常依赖/etc/nginx/下文件读取——权限不足仍会失败，得一并放开路径或用Defaults env_reset控制环境变量
为什么 getfacl 显示 default 条目却不起作用？
常见假阳性：getfacl 看到 default: 行，但新文件没继承 ACL——问题几乎总出在底层支撑环节。
- 先运行
mount | grep "$(df . | tail -1 | awk '{print $1}')" | grep acl，确认文件系统挂载时带acl选项；没有就白搭 - 检查父目录是否真的可写可执行：
ls -ld /shared/project，若权限是drwxr-xr-x，组和其他人缺 w，新文件根本创建不了，更别说继承 ACL - 验证时用真实用户测试：切到
su - alice，在目录里touch test，再getfacl test；用 root 创建的文件不走默认 ACL 流程 - 某些 NFS 或 CIFS 挂载不支持 ACL 继承，即便本地
setfacl -d成功，远程客户端也看不到效果
真正难的不是命令怎么敲，而是搞清权限生效链路：文件系统支持 → 目录基础权限允许创建 → umask 不过滤关键位 → 用户实际执行创建动作 → ACL 规则匹配生效。任一环断开，配置就静默失效。
