[PATCH] qemu_namespace: Umount the original /dev before replacing it with tmpfs

Jim Fehlig jfehlig at suse.com
Wed Jan 18 00:58:50 UTC 2023


On 12/16/22 08:04, Michal Privoznik wrote:
> Our code relies on mount events propagating into the namespace we
> create for a domain. However, there's one caveat. In v8.8.0-rc1~8
> I've tried to make us detect differences in mount tables between
> the namespace in which libvirtd runs and the domain namespace.
> This is crucial for any mounts that happen after the domain was
> started (for instance new hugetlbfs can be mounted on say
> /dev/hugepages1G).
> 
> Therefore, we take a look into /proc/$(pgrep qemu)/mounts to see
> what filesystems are mounted under /dev. Now, since we don't
> umount the original /dev, just mount a tmpfs over it, we get all
> the events (e.g. aforementioned hugetlbfs mount on
> /dev/hugepages1G), but we are not really able to access it
> because of the tmpfs that's placed on top. This then confuses our
> algorithm for detecting which filesystems are mounted (the
> algorithm is implemented in qemuDomainGetPreservedMounts()).
> 
> To break the link between host's and guest's /dev we just need to
> umount() the original /dev in the namespace. Just before our
> artificially created tmpfs is moved into its place.
> 
> Fixes: 46b03819ae8d833b11c2aaccb2c2a0361727f51b
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2151869#c6
> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> ---
>   src/qemu/qemu_namespace.c | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/src/qemu/qemu_namespace.c b/src/qemu/qemu_namespace.c
> index 90c0b90024..a6b9af1307 100644
> --- a/src/qemu/qemu_namespace.c
> +++ b/src/qemu/qemu_namespace.c
> @@ -775,6 +775,11 @@ qemuDomainUnshareNamespace(virQEMUDriverConfig *cfg,
>               goto cleanup;
>       }
>   
> +    if (umount("/dev") < 0) {
> +        virReportSystemError(errno, "%s", _("failed to umount devfs on /dev"));
> +        return -1;
> +    }

Hi Michal,

While doing some downstream testing of 9.0.0 with apparmor confinement of 
libvirtd enabled, I encountered the above error when attempting to start a VM. 
Additionally from the audit subsystem

kernel: audit: type=1400 audit(1674002774.461:13): apparmor="DENIED" 
operation="umount" profile="libvirtd" name="/dev/" pid=4778 comm="rpc-libvirtd"

Hmm, libvirtd needs to umount /dev, is that right? I added

    umount /dev/,

to the usr.sbin.libvirtd profile, reloaded it, and was then able to start the 
VM. That seems like a big hammer. I was expecting the umount in 
/run/libvirt/qemu/*.dev, but the profile already contains a rule for that path.

Regards,
Jim



More information about the libvir-list mailing list