多用户环境中ACL强制访问需文件系统启用acl挂载、默认ACL与当前ACL双设、umask协同及父目录权限管控。须验证挂载选项、getfacl输出、三步测试越权操作是否被阻断。
在多用户开发环境中，基于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应能正常输出，且包含# file: /testdir等完整结构；若报“Operation not supported”，说明挂载未生效或文件系统类型不支持（如某些旧版vfat）
用默认ACL + 当前ACL双层绑定实现“强制继承”
仅设-d（default）ACL，只影响新创建的文件/子目录；但已有内容仍可被误改。要达到“目录级别强制”，必须同时作用于当前项与未来项：
- 对协作目录（如/dev/project）先设默认ACL：setfacl -d -m u:alice:rwX,g:devteam:rwX,o::--- /dev/project（o::---彻底禁用其他用户）
- 再立即补当前ACL，使已有文件/子目录立刻受控：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，实现“谁创建谁删除”原则
验证是否真正“强制”：三步测试法
配置后不测试=未生效。以下操作必须由不同用户分别执行，才能暴露真实问题：
- 切换至非属主用户（如su - alice），在目标目录下创建文件：touch test.sh && mkdir testsub
- 检查新文件ACL：getfacl test.sh应显示user:alice:rw-及group:devteam:rw-；getfacl testsub还应含default:条目
- 尝试越权操作：echo "hacked" > /dev/project/owner_file.txt（该文件属别人）——若成功，说明父目录w权限未收敛；若getfacl里没出现alice条目，说明默认ACL未生效或umask拦截
