From ce01a2b11ce88da772923ebcbbfe66f228a7bfee Mon Sep 17 00:00:00 2001
From: Michal Privoznik <mprivozn@redhat.com>
Date: Wed, 4 Jan 2017 14:06:09 +0100
Subject: [PATCH] qemuDomainAttachDeviceMknodHelper: Don't unlink() so often

Not that I'd encounter any bug here, but the code doesn't look
100% correct. Imagine, somebody is trying to attach a device to a
domain, and the device's /dev entry already exists in the qemu
namespace. This is handled gracefully and the control continues
with setting up ACLs and calling security manager to set up
labels. Now, if any of these steps fail, control jump on the
'cleanup' label and unlink() the file straight away. Even when it
was not us who created the file in the first place. This can be
possibly dangerous.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
 src/qemu/qemu_domain.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index ad80be034b..4eff2ef460 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -7523,6 +7523,7 @@ qemuDomainAttachDeviceMknodHelper(pid_t pid ATTRIBUTE_UNUSED,
 {
     struct qemuDomainAttachDeviceMknodData *data = opaque;
     int ret = -1;
+    bool delDevice = false;
 
     virSecurityManagerPostFork(data->driver->securityManager);
 
@@ -7545,6 +7546,8 @@ qemuDomainAttachDeviceMknodHelper(pid_t pid ATTRIBUTE_UNUSED,
                                  data->file);
             goto cleanup;
         }
+    } else {
+        delDevice = true;
     }
 
     if (virFileSetACLs(data->file, data->acl) < 0 &&
@@ -7608,7 +7611,7 @@ qemuDomainAttachDeviceMknodHelper(pid_t pid ATTRIBUTE_UNUSED,
 
     ret = 0;
  cleanup:
-    if (ret < 0)
+    if (ret < 0 && delDevice)
         unlink(data->file);
     virFileFreeACLs(&data->acl);
     return ret;
-- 
GitLab