[PATCH] qemu_namespace: Deal with nested mounts when umount()-ing /dev
Jim Fehlig
jfehlig at suse.com
Tue Feb 7 18:42:14 UTC 2023
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
More information about the libvir-list
mailing list