[PATCH] qemu_namespace: Deal with nested mounts when umount()-ing /dev

[Jim Fehlig]

On 2/7/23 08:02, Michal Privoznik wrote:
> In one of recent commits (v9.0.0-rc1~106) I've made our QEMU
> namespace code umount the original /dev. One of the reasons was
> enhanced security, because previously we just mounted a tmpfs
> over the original /dev. Thus a malicious QEMU could just
> umount("/dev") and it would get to the original /dev with all
> nodes.
> 
> Now, on some systems this introduced a regression:
> 
>     failed to umount devfs on /dev: Device or resource busy
> 
> But how this could be? We've moved all file systems mounted under
> /dev to a temporary location. Or have we? As it turns out, not
> quite. If there are two file systems mounted on the same target,
> e.g. like this:
> 
>    mount -t tmpfs tmpfs /dev/shm/ && mount -t tmpfs tmpfs /dev/shm/
> 
> then only the top most (i.e. the last one) is moved. See
> qemuDomainUnshareNamespace() for more info.
> 
> Now, we could enhance our code to deal with these "doubled" mount
> points. Or, since it is the top most file system that is
> accessible anyways (and this one is preserved), we can
> umount("/dev") in a recursive fashion.
> 
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2167302
> Fixes: 379c0ce4bfed8733dfbde557c359eecc5474ce38
> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> ---
>   src/qemu/qemu_namespace.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/qemu/qemu_namespace.c b/src/qemu/qemu_namespace.c
> index 5769a4dfe0..5fc043bd62 100644
> --- a/src/qemu/qemu_namespace.c
> +++ b/src/qemu/qemu_namespace.c
> @@ -777,7 +777,7 @@ qemuDomainUnshareNamespace(virQEMUDriverConfig *cfg,
>       }
>   
>   #if defined(__linux__)
> -    if (umount("/dev") < 0) {
> +    if (umount2("/dev", MNT_DETACH) < 0) {
>           virReportSystemError(errno, "%s", _("failed to umount devfs on /dev"));
>           return -1;
>       }

Reviewed-by: Jim Fehlig <jfehlig at suse.com>

Thanks for the investigating the problem and providing a reproducer and a fix!

Regards,
Jim