Given是一个具有pid=host的容器(因此它位于初始PID命名空间中，并且可以完整查看所有进程(。这个容器(更确切地说，它的进程(还具有CAP_SYS_ADMIN和CAP_SYS_CHROOT功能，因此它可以使用setns(2)更改装载名称空间。
- 是否可以使用AppArmor阻止此容器访问主机(初始装载命名空间(中的任意文件，但某些文件除外，如
/var/run/foo - AppArmor如何根据装载命名空间评估文件系统路径名？是不是"；忽略"；挂载名称空间并只采用指定的路径，或者它是否转换路径，例如在处理绑定挂载的子树时，等等
AppArmor体系结构的一个根深蒂固的限制是，在文件系统资源(文件、目录(的情况下，它使用访问路径来中介访问。虽然AppArmor和SELinux一样使用标签，但AppArmor仅从访问路径派生隐式文件系统资源标签。相反，SELinux使用显式标签，这些标签存储在支持POSIX扩展属性的文件系统的扩展属性中。
现在，访问路径始终是调用方当前装载命名空间中的路径。AppArmor也可以考虑chroot。所以第二个问题的答案是：AppArmor"；忽略"；装载名称空间并只采用(访问(路径。据我所知，它并没有翻译绑定挂载(没有任何迹象表明它会这么做(。
关于第一个问题项目：；否"；，由于AppArmor中介访问路径(标签(，而不是文件资源标签。当接受容器内部的内容和容器外部的主机中的内容之间不会有任何访问路径差异时，有限的访问限制是可能的(与其他容器内部的相同(。这基本上就是Docker的默认容器AppArmor配置文件所做的：将所有访问权限限制为几个高度敏感的/proc/条目，并将许多其他/proc/条目的只读访问权限限制。
但是，阻止对某些主机文件访问路径的访问总是伴随着阻止同一访问路径在容器(不同的装载命名空间(内完全有效使用的危险，因此这需要非常小心、大量的研究和测试，以及在容器的下一次更新中不断发生故障的危险。AppArmor似乎不是为此类用例而设计的。