acl实现web服务器多角色目录访问限制的核心是将角色映射为系统组（如devgrp、opsgrp）或用户，通过setfacl精确授权读写执行权限，并同步设置当前acl与带-d参数的默认acl以确保新文件自动继承；web服务用户（如www-data）须单独授权且不可加入业务组；需区分目录与文件权限语义，禁用other权限，定期用getfacl核验并避免chmod -r破坏acl。

Web服务器上用ACL实现基于角色的目录访问限制，核心是把“角色”映射为系统用户或组，再通过setfacl为不同角色赋予精确的读、写、执行权限，同时配合默认ACL确保新文件自动继承。它不改动原有属主结构，也不依赖全局chmod，适合开发、运维、内容编辑等多角色共管同一站点目录的场景。

角色到系统实体的映射要明确

ACL本身不定义角色，需先在系统层面落实角色载体：

• 优先使用组（group）代表角色：如创建devgrp（开发）、opsgrp（运维）、editorgrp（内容编辑），再将对应人员加入组
• 对需特殊权限的个体（如技术负责人），可单独添加用户级ACL条目，避免扩大组权限范围
• Web服务运行用户（如www-data或nginx）必须单独授权，不可直接加入业务组，防止越权

按角色分层设置当前ACL与默认ACL

仅设当前ACL不够——新上传或创建的文件/子目录不会自动获得权限。必须同步配置默认ACL（带-d参数）：

• 对协作根目录（如/var/www/example.com）执行：
  setfacl -m g:devgrp:rwx,g:opsgrp:rx,u:www-data:r-x /var/www/example.com
• 立即启用继承能力：
  setfacl -d -m g:devgrp:rwx,g:opsgrp:rx,u:www-data:r-x /var/www/example.com
• 敏感子目录单独收紧：如配置目录禁止编辑组访问，用setfacl -m g:editorgrp:--- /var/www/example.com/config

权限组合要匹配实际操作需求

目录和文件的权限含义不同，ACL需区分设置：

• 对目录：执行（x）= 进入该目录，读（r）= 列出内容，写（w）= 创建/删除文件；三者常需组合（如rwx）
• 对静态文件（HTML/CSS/JS）：通常只需r--给Web服务用户和协作组，无需执行权限
• 对可执行脚本或上传目录：需显式加x（脚本）或w（上传），但应限定在专用子路径下（如/uploads）
• 注意mask影响：ACL实际生效受mask限制，若基础组权限是rx，即使ACL加了w也无效；必要时用setfacl -m m::rwx临时调高mask

验证与维护不能只靠一次性设置

ACL规则易被chmod或复制操作覆盖，需建立轻量检查机制：

• 快速查看全量ACL：getfacl -R /var/www/example.com | grep -E "^(#|user:|group:|other:)"
• 重点核对三项：默认ACL是否存在、www-data权限是否合理、其他用户（other）是否已禁用（o::---）
• 避免用chmod -R递归修改目录权限，它会重置ACL中的mask并可能清除自定义条目
• 上线前用各角色账户实测：能否进入目录、列出文件、上传/修改/删除目标文件