External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2025-01-21 20:15:17 +00:00
Code Issues Packages Projects Releases Wiki Activity

qemuDomainAttachDeviceMknodHelper: Don't unlink() so often

Browse Source 
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>
This commit is contained in:
Michal Privoznik 2017-01-04 14:06:09 +01:00
parent 3aae99fe71
commit ce01a2b11c
1 changed files with 4 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
src/qemu/qemu_domain.c
View File

@ -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;