应立即收紧宿主机ACL配置：①用getfacl检查并移除非必要user/group条目；②仅添加容器所需UID的精确rw-权限；③执行setfacl -k禁用默认继承；④配合--user和userns-remap双重约束，禁用执行位。
宿主机ACL（Access Control List）规则设置过宽，比如对挂载目录赋予了不必要用户或组的读写执行权限（如 setfacl -m u:otheruser:rwx /host/data），可能使容器内非预期用户获得越权访问能力——尤其当容器以该用户UID运行时，即可绕过常规文件权限限制，读取敏感配置、覆盖关键数据，甚至配合CVE-2023-28842类漏洞完成跨挂载点提权。
立即检查并收紧ACL配置
先确认目标挂载路径是否启用了ACL，并识别宽松条目：
- 运行
getfacl /host/data查看完整ACL列表，重点关注user:、group:和mask:行； - 若输出中存在非业务必需的
user:xxx:rwx或group:yyy:rwx，即为风险点； - 特别注意
mask::rwx—— 它会放大所有命名用户/组的实际权限，应降为mask::rwx仅保留最小必要位（如mask::r-x或mask::rw-）。
用最小权限原则重设ACL
只授予容器运行用户（UID）及其所属组精确权限，禁用通配与继承：
- 移除所有非必要命名条目：
setfacl -x u:untrusteduser,g:untrustedgroup /host/data； - 仅添加容器所需用户：
setfacl -m u:1001:rw- /host/data（假设容器以 UID 1001 运行）； - 禁用默认ACL继承（防止子目录自动继承宽松策略）：
setfacl -k /host/data； - 验证结果：
getfacl /host/data中应仅含user::、group::、other::及显式添加的user:1001:条目，无多余user:或group:。
结合Docker安全机制做双重防护
ACL只是文件系统层控制，需叠加容器运行时约束：
- 启动容器时强制指定用户，避免依赖默认root：
docker run -v /host/data:/data --user 1001:1001 image； - 启用 user namespace remap（在
/etc/docker/daemon.json中配置"userns-remap": "default"），使容器内 UID 1001 映射为宿主机高位UID（如 100100），即使ACL误配也不会影响真实业务账户； - 对敏感挂载路径禁用执行权限（防止上传恶意二进制）：
chmod -x /host/data，再通过ACL补回读写（setfacl -m u:1001:rw- /host/data）。
ACL不是“开个口子让容器进来”，而是“只开一道窄门，且门后还设岗哨”。收紧它，再叠一层用户映射和只读限制，越权路径就基本堵死了。
