关键在于ACL不可绕过、自动继承且服务稳定运行，需文件系统启用ACL、双层ACL设置、umask协同、父目录权限封堵及服务用户精准授权四者缺一不可。

在多用户开发环境中，基于ACL实现目录级别的强制访问，**关键不是“设了权限”，而是让权限不可绕过、自动继承、且系统服务能稳定运行**。这需要文件系统支持、ACL双层设置（当前+默认）、umask协同、父目录权限封堵，以及对服务用户的精准授权——四者缺一不可。

确保文件系统真正启用ACL并挂载正确

ACL不是默认就“可用”的功能，它依赖底层文件系统挂载时显式开启。很多问题看似ACL没生效，实则是挂载参数缺失：

• 运行mount | grep "$(df . | tail -1 | awk '{print $1}')" | grep acl，确认当前工作分区挂载选项含acl；若无，临时重挂：sudo mount -o remount,acl /path/to/mount
• 永久生效需编辑/etc/fstab，在对应分区行的挂载选项中加入acl（如defaults,acl），再执行sudo mount -o remount /
• 验证是否就绪：getfacl /testdir应能正常输出完整结构；若报“Operation not supported”，说明挂载未生效或文件系统类型不支持（如vfat）

用默认ACL + 当前ACL双层绑定实现“强制继承”

仅设-d（default）ACL，只影响新创建的文件/子目录；但已有内容仍可被误改。要达到“目录级别强制”，必须同时作用于当前项与未来项：

• setfacl -d -m u:alice:rwX,g:devteam:rwX,o::--- /dev/project（o::---彻底禁用其他用户）
• setfacl -m u:alice:rwX,g:devteam:rwX,o::--- /dev/project
• 注意大小写：X表示“仅对目录或已有执行位的文件添加x”，避免脚本被意外剥夺执行权；而x会强行加执行，可能带来安全风险

配合umask与父目录权限封堵绕过路径

即使ACL设好，用户仍可能因umask过严导致新建文件权限不足，或因父目录w权限开放而删除他人文件——这两点常被忽略，却直接破坏“强制性”：

• 协作用户统一设置宽松umask（如umask 002），写入/etc/profile或~/.bashrc，确保新建文件基础权限为664、目录为775，从而让ACL中的rwX真正落地
• 父目录自身权限需限制：例如/dev/project的组权限应为r-x（即chmod 750 /dev/project），这样即使某用户属于devteam组，也无法删除该目录下非自己创建的文件
• 进一步加固可加sticky bit：chmod g+s /dev/project，配合属组设为devteam，实现“谁创建谁删除”原则

系统服务用户必须单独授权且隔离运行

服务进程（如git-daemon、jenkins、或自研构建服务）通常以专用用户（如git、jenkins）运行，其权限不能靠加入业务组获得，必须通过ACL显式授予，并严格隔离：

• 先确认服务运行身份：ps aux | grep jenkins 或查看systemd unit文件中User=字段
• 为服务用户单独授权：setfacl -m u:jenkins:r-x /dev/project（目录读取+进入）和setfacl -R -m u:jenkins:r-- /dev/project（递归只读文件）
• 严禁将服务用户加入devteam等业务组，否则ACL策略形同虚设；ACL授权更清晰、可审计、易回溯
• 若服务需写入（如CI流水线生成构建产物），应在专用子路径下授权，例如：setfacl -m u:jenkins:rwx /dev/project/builds，并同步设默认ACL