So recently I have been asked if we can remove our use of mnt_ns->root for some vfs cleanups. However being backwards compatible is turning into a pain.
We use the mnt_ns->root for two things, to detect that we are in a chroot and if we are, it determines the visibility of the returned path. Removing access to mnt_ns->root will remove our ability to detect that we are in a chroot, and to determine path visibility when in a chroot. So the question arises of why do we want to detect that we are in a chroot? This allows resolving paths to the file system namespace root (ie. the path before the chroot was done). This makes it so that all accesses done within the chroot to apparmor look like accesses prechroot. ie. if we chroot to /var/chroot/ then accesses with in the chroot to /etc/ still look like /var/chroot/etc Doing this was a way of avoiding path aliasing of pre and post chroot paths within a profile. The alternative was changing profile for pre and post chroot mediation, which is a better solution as outline in https://lists.ubuntu.com/archives/apparmor/2011-December/001776.html However requiring profile transitions does not provide compatibility with older policy. I have not been able to come up with a viable solution that matches the old semantics. I think we are just going to have to require that older profiles be modified, or use an older kernel. The semantics of mediating the path outside of the chroot are dubious at best, so from a security stand point making the move makes sense. john -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
