On 05/05/2011 05:51 AM, Daniel P. Berrange wrote:
> Wire up logging of VM taintint to the QEMU driver
s/taintint/tainting/
>
> - If running QEMU as root user/group or without capabilities
> being cleared
> - If passing custom QEMU command line args
> - If issuing custom QEMU monitor commands
> - If using a network interface config with an associated
> shell script
> - If using a disk config relying on format probing
>
> The warnings, per-VM appear in the main libvirtd logs
>
> 11:56:17.571: 10832: warning : qemuDomainObjTaint:712 : Domain id=1 name='l2' uuid=c7a3edbd-edaf-9455-926a-d65c16db1802 is tainted: high-privileges
> 11:56:17.571: 10832: warning : qemuDomainObjTaint:712 : Domain id=1 name='l2' uuid=c7a3edbd-edaf-9455-926a-d65c16db1802 is tainted: disk-probing
>
> The taint flags are reset when the VM is stopped.
>
> * src/qemu/qemu_domain.c, src/qemu/qemu_domain.h: Helper APIs
> for logging taint warnings
> * src/qemu/qemu_driver.c: Log tainting with custom QEMU monitor
> commands and disk/net hotplug with unsupported configs
> * src/qemu/qemu_process.c: Log tainting at startup based on
> unsupported configs
> +++ b/src/qemu/qemu_driver.c
> @@ -3877,6 +3877,7 @@ qemuDomainAttachDeviceLive(virDomainObjPtr vm,
>
> switch (dev->type) {
> case VIR_DOMAIN_DEVICE_DISK:
> + qemuDomainObjCheckDiskTaint(driver, vm, dev->data.disk);
> ret = qemuDomainAttachDeviceDiskLive(driver, vm, dev);
Do we really want to issue the taint message before attempting the
attach? Or are we still safe if you perform the attach first, and issue
the taint message only on success?
> if (!ret)
> dev->data.disk = NULL;
> @@ -3889,6 +3890,7 @@ qemuDomainAttachDeviceLive(virDomainObjPtr vm,
> break;
>
> case VIR_DOMAIN_DEVICE_NET:
> + qemuDomainObjCheckNetTaint(driver, vm, dev->data.net);
> ret = qemuDomainAttachNetDevice(dom->conn, driver, vm,
Likewise.
On second thought - we can't guarantee if failure happened before a disk
was probed, or after, so I guess doing unconditional taint is the
conservatively safe approach, and the whole point of this is
conservative safety even if it lets through some false positives.
So, ACK.
--
Eric Blake eblake@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list