October 2013 - Devel - libvirt List Archives

[libvirt] [PATCH 00/14] Fix flaw in virt-login-shell CVE-2013-4400
by Daniel P. Berrange 24 Dec '13

24 Dec '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> The following series of patches have been pushed to master as a fix for CVE-2013-4400. The first four patches are the core fix. The remaining 10 patches are preventative measures to help avoid further problems in the future. I will be pushing at least the first 4 patches to stable branches and any of the further patches if I find they apply without merge problems. Daniel P. Berrange (14): Add helpers for getting env vars in a setuid environment Only allow 'stderr' log output when running setuid (CVE-2013-4400) Close all non-stdio FDs in virt-login-shell (CVE-2013-4400) Don't link virt-login-shell against libvirt.so (CVE-2013-4400) Set a sane $PATH for virt-login-shell Make virCommand env handling robust in setuid env Remove all direct use of getenv Block all use of getenv with syntax-check Only allow the UNIX transport in remote driver when setuid Don't allow remote driver daemon autostart when running setuid Add stub getegid impl for platforms lacking it Remove (nearly) all use of getuid()/getgid() Block all use of libvirt.so in setuid programs Move virt-login-shell into libvirt-login-shell sub-RPM Makefile.am | 1 + bootstrap.conf | 1 + cfg.mk | 8 ++++ config-post.h | 44 ++++++++++++++++++ configure.ac | 1 + daemon/Makefile.am | 1 + daemon/libvirtd.c | 2 +- examples/domain-events/events-c/Makefile.am | 3 +- examples/hellolibvirt/Makefile.am | 2 +- examples/openauth/Makefile.am | 2 +- gnulib/lib/Makefile.am | 2 +- libvirt.spec.in | 28 +++++++---- python/Makefile.am | 1 + src/Makefile.am | 72 +++++++++++++++++++++++++++++ src/driver.c | 3 +- src/libvirt.c | 54 +++++++++++++++------- src/libvirt_private.syms | 6 ++- src/locking/lock_daemon.c | 6 +-- src/locking/lock_driver_lockd.c | 6 +-- src/locking/lock_manager.c | 2 +- src/lxc/lxc_controller.c | 2 +- src/lxc/lxc_driver.c | 4 +- src/lxc/lxc_process.c | 2 +- src/qemu/qemu_command.c | 8 ++-- src/qemu/qemu_driver.c | 6 +-- src/remote/remote_driver.c | 37 +++++++++++---- src/rpc/virnetsocket.c | 16 +++---- src/rpc/virnettlscontext.c | 4 +- src/storage/storage_backend.c | 4 +- src/storage/storage_backend_fs.c | 4 +- src/storage/storage_backend_logical.c | 2 +- src/util/virauth.c | 2 +- src/util/vircommand.c | 50 +++++++++++++++----- src/util/vircommand.h | 8 +++- src/util/virfile.c | 23 +++++---- src/util/viridentity.c | 8 ++-- src/util/virlog.c | 18 ++++++-- src/util/virrandom.c | 2 +- src/util/virstoragefile.c | 2 +- src/util/virutil.c | 47 +++++++++++++++++-- src/util/virutil.h | 8 ++++ src/vbox/vbox_XPCOMCGlue.c | 2 +- src/vbox/vbox_driver.c | 2 +- src/vbox/vbox_tmpl.c | 6 +-- tests/commandtest.c | 8 ++-- tests/qemumonitortestutils.c | 2 +- tests/virnetsockettest.c | 4 +- tools/Makefile.am | 9 +++- tools/virsh.c | 18 ++++---- tools/virt-login-shell.c | 14 ++++++ 50 files changed, 430 insertions(+), 137 deletions(-) create mode 100644 config-post.h -- 1.8.3.1

2 16

[libvirt] JNA Error Callback could cause core dump.
by Benjamin Wang (gendwang) 20 Dec '13

20 Dec '13

Hi, When I changed code as following: public class Connect { // Load the native part static { Libvirt.INSTANCE.virInitialize(); try { ErrorHandler.processError(Libvirt.INSTANCE); } catch (Exception e) { e.printStackTrace(); } + Libvirt.INSTANCE.virSetErrorFunc(null, new ErrorCallback()); } The server will generate the following core dump: Program terminated with signal 6, Aborted. #0 0x0000003f9b030265 in raise () from /lib64/libc.so.6 (gdb) where #0 0x0000003f9b030265 in raise () from /lib64/libc.so.6 #1 0x0000003f9b031d10 in abort () from /lib64/libc.so.6 #2 0x0000003f9b06a84b in __libc_message () from /lib64/libc.so.6 #3 0x0000003f9b07230f in _int_free () from /lib64/libc.so.6 #4 0x0000003f9b07276b in free () from /lib64/libc.so.6 #5 0x00002aaaacf46868 in ?? () #6 0x0000000000000000 in ?? () The problem was caused that when JNA call setErrorFunc, it will create ErrorCallback object. But when GC is executed, the object is GCed. But even I change code as following. When GC is excuted, the callback object will be moved. Then C can't find this object. Both of scenarios will cause core dump. It seems that JNA mustn't provide ErrorCallback Class, Because nobody can use this. Please correct me. public class Connect { + private static final ErrorCallback callback = new ErrorCallback(); // Load the native part static { Libvirt.INSTANCE.virInitialize(); try { ErrorHandler.processError(Libvirt.INSTANCE); } catch (Exception e) { e.printStackTrace(); } + Libvirt.INSTANCE.virSetErrorFunc(null, callback); } B.R. Benjamin Wang

2 4

[libvirt] [PATCH 0/5] Fill qemucapabilitiesdata with some data
by Michal Privoznik 20 Dec '13

20 Dec '13

The actual patches are accessible at: git://gitorious.org/libvirt/michal-staging.git branch test_qemu_capabilities_data I'm not sending the actual patches as it's big junk of JSON qemu replies. The patches has from 35KiB to 59KiB. I don't want to overload the list. Michal Privoznik (5): qemucapabilitiesdata: Add qemu-1.2.2 data qemucapabilitiesdata: Add qemu-1.3.1 data qemucapabilitiesdata: Add qemu-1.4.2 data qemucapabilitiesdata: Add qemu-1.6.0 data qemucapabilitiesdata: Add qemu-1.6.50 data tests/qemucapabilitiesdata/caps_1.2.2-1.caps | 114 + tests/qemucapabilitiesdata/caps_1.2.2-1.replies | 1543 +++++++++++++ tests/qemucapabilitiesdata/caps_1.3.1-1.caps | 128 ++ tests/qemucapabilitiesdata/caps_1.3.1-1.replies | 1715 +++++++++++++++ tests/qemucapabilitiesdata/caps_1.4.2-1.caps | 129 ++ tests/qemucapabilitiesdata/caps_1.4.2-1.replies | 1765 +++++++++++++++ tests/qemucapabilitiesdata/caps_1.6.0-1.caps | 137 ++ tests/qemucapabilitiesdata/caps_1.6.0-1.replies | 2499 ++++++++++++++++++++++ tests/qemucapabilitiesdata/caps_1.6.50-1.caps | 136 ++ tests/qemucapabilitiesdata/caps_1.6.50-1.replies | 2476 +++++++++++++++++++++ tests/qemucapabilitiestest.c | 5 + 11 files changed, 10647 insertions(+) create mode 100644 tests/qemucapabilitiesdata/caps_1.2.2-1.caps create mode 100644 tests/qemucapabilitiesdata/caps_1.2.2-1.replies create mode 100644 tests/qemucapabilitiesdata/caps_1.3.1-1.caps create mode 100644 tests/qemucapabilitiesdata/caps_1.3.1-1.replies create mode 100644 tests/qemucapabilitiesdata/caps_1.4.2-1.caps create mode 100644 tests/qemucapabilitiesdata/caps_1.4.2-1.replies create mode 100644 tests/qemucapabilitiesdata/caps_1.6.0-1.caps create mode 100644 tests/qemucapabilitiesdata/caps_1.6.0-1.replies create mode 100644 tests/qemucapabilitiesdata/caps_1.6.50-1.caps create mode 100644 tests/qemucapabilitiesdata/caps_1.6.50-1.replies -- 1.8.1.5

3 9

[libvirt] [PATCH 0/4] Support for integrating cgroups with systemd
by Daniel P. Berrange 16 Dec '13

16 Dec '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> This is a much changed / expanded version of my previous work to create cgroups via systemd. The difference is that this time it actually works :-) I'm not proposing this for merge until after the 1.1.1 release. Daniel P. Berrange (4): Add APIs for formatting systemd slice/scope names Add support for systemd cgroup mount Cope with races while killing processes Enable support for systemd-machined in cgroups creation src/libvirt_private.syms | 2 + src/lxc/lxc_process.c | 10 +- src/qemu/qemu_cgroup.c | 1 + src/util/vircgroup.c | 270 +++++++++++++++++++++++++++++++++++++++++------ src/util/vircgroup.h | 2 + src/util/virsystemd.c | 96 ++++++++++++++++- src/util/virsystemd.h | 5 + tests/vircgrouptest.c | 9 ++ tests/virsystemdtest.c | 48 +++++++++ 9 files changed, 403 insertions(+), 40 deletions(-) -- 1.8.1.4

4 16

[libvirt] Internal error message from netcf when trying to start libvirtd
by Christophe Fergeau 03 Dec '13

03 Dec '13

Hey, Due to a configuration issue on my system, libvirtd is not starting on my system (not complaining about this!): 2013-10-15 15:40:51.024+0000: 10222: info : libvirt version: 1.1.3 2013-10-15 15:40:51.024+0000: 10222: error : virNetTLSContextCheckCertFile:117 : Cannot read CA certificate '/home/teuf/usr/etc/pki/CA/cacert.pem': No such file or directory However, before libvirtd exits, I get another error message from the netcf code, which is unexpected this time: 2013-10-15 15:49:18.361+0000: 10222: error : netcfStateCleanup:105 : internal error: Attempt to close netcf state driver already closed This message comes from the call of virStateCleanup() at the end of main() in libvirtd.c. virStateCleanup() should not be called before daemonStateInit() has been called in main. After this call, things get more ugly as daemonStateInit() calls virStateInitialize() from a thread, so there's probably a small window for virStateInitialize() and virStateCleanup() running concurrently if an error occurs between the call to daemonStateInit() and the call to virNetServerRun(). I'm sending this email rather than a patch as I'm not sure what is the best way to fix it. The easy way would be for virStateCleanup() to be a noop when virStateInitialize() hasn't been called (iow remove the error message from netcfStateCleanup). However, this would leave this small race condition around (which is not that bad as it would only occurs in situations when the daemon fails to start). So another approach would be to set a vir_state_initialized boolean once the thread has called ivrStateInitialize, and only call virStateCleanup() when it's set. Or maybe there's a 3rd way to fix this? Let me know if you have any guidance into the best way to fix this, Christophe

3 7

[libvirt] [PATCH 0/3 RESEND] qemu: Hotplug SCSI controllers/hostdevs
by Eric Farman 21 Nov '13

21 Nov '13

(Resending, as this has perhaps been lost during the release of 1.1.3. I've rebased this patch series onto today's git repository.) Today, hotplug of a SCSI hostdev relies on the presence of an existing SCSI controller, which can be defined in the initial domain XML. Hotplug of a SCSI controller relies on the presence of a PCI bus, which does not work in all environments. These patches correct this behavior, in order to allow hotplug (and unplug) work without incident. Reviewed-by: Viktor Mihajlovski <mihajlov(a)linux.vnet.ibm.com> Eric Farman (3): qemu: Rename controller hotplug functions to not be PCI-specific qemu: Separate calls based on controller bus type qemu: Auto-generate controller for hotplugged hostdev src/qemu/qemu_driver.c | 4 +-- src/qemu/qemu_hotplug.c | 62 ++++++++++++++++++++++++++++++++--------------- src/qemu/qemu_hotplug.h | 12 ++++----- 3 files changed, 50 insertions(+), 28 deletions(-) -- 1.7.9.5

4 15

[libvirt] [PATCH v2] virsh domxml-from-native to treat SCSI as the bus type for pseries by default
by Shivaprasad G Bhat 16 Nov '13

16 Nov '13

The bus type IDE being enum Zero, the bus type on pseries system appears as IDE for all the disk types. Pseries platform needs this to appear as SCSI instead of IDE. Signed-off-by: Shivaprasad G Bhat <sbhat(a)linux.vnet.ibm.com> --- src/qemu/qemu_domain.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index b8aec2d..df06c13 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -827,6 +827,12 @@ qemuDomainDeviceDefPostParse(virDomainDeviceDefPtr dev, if (dev->type == VIR_DOMAIN_DEVICE_DISK) { virDomainDiskDefPtr disk = dev->data.disk; + if ((def->os.arch == VIR_ARCH_PPC64) && + def->os.machine && STREQ(def->os.machine, "pseries") && + (disk->bus == VIR_DOMAIN_DISK_BUS_IDE)) { + disk->bus = VIR_DOMAIN_DISK_BUS_SCSI; + } + /* both of these require data from the driver config */ if (driver && (cfg = virQEMUDriverGetConfig(driver))) { /* assign default storage format and driver according to config */ @@ -868,6 +874,11 @@ qemuDomainDeviceDefPostParse(virDomainDeviceDefPtr dev, (def->os.arch == VIR_ARCH_S390 || def->os.arch == VIR_ARCH_S390X)) dev->data.chr->targetType = VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_VIRTIO; + if (dev->type == VIR_DOMAIN_DEVICE_CONTROLLER && + dev->data.controller->type == VIR_DOMAIN_CONTROLLER_TYPE_IDE && + def->os.machine && STREQ(def->os.machine, "pseries")) + dev->data.controller->type = VIR_DOMAIN_CONTROLLER_TYPE_SCSI; + /* set the default USB model to none for s390 unless an address is found */ if (dev->type == VIR_DOMAIN_DEVICE_CONTROLLER && dev->data.controller->type == VIR_DOMAIN_CONTROLLER_TYPE_USB &&

5 12

[libvirt] [PATCH v2]virsh: track alias option and improve error message when option duplicates its alias
by Chen Hanxiao 14 Nov '13

14 Nov '13

From: Chen Hanxiao <chenhanxiao(a)cn.fujitsu.com> commit 2b172a8effa712aee97a21a64d2d02060958f9b2 allow alias to expand to opt=value pair. That means alias may not look alike since then. With this patch we will also track alias. If we type command with one option and another marked as its alias, we will get an error message like: error: option '--AA' duplicates its alias '--AAA' Signed-off-by: Chen Hanxiao <chenhanxiao(a)cn.fujitsu.com> --- v2: do not depend on orders of options in array. Alias could be anywhere except after the default one. tools/virsh.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/tools/virsh.c b/tools/virsh.c index bad78c9..ffead84 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -1071,6 +1071,7 @@ vshCmddefGetOption(vshControl *ctl, const vshCmdDef *cmd, const char *name, size_t i; const vshCmdOptDef *ret = NULL; char *alias = NULL; + char *tmp_name = NULL; if (STREQ(name, helpopt.name)) { return &helpopt; @@ -1101,6 +1102,13 @@ vshCmddefGetOption(vshControl *ctl, const vshCmdDef *cmd, const char *name, if (VIR_STRDUP(*optstr, value + 1) < 0) goto cleanup; } + tmp_name = vshMalloc(NULL, strlen(name) + 3); + snprintf(tmp_name, strlen(name) + 3, "--%s", name); + if (strstr(rl_line_buffer, tmp_name)) { + vshError(ctl, _("option '--%s' duplicates its alias '--%s'"), + cmd->opts[i].name, name); + goto cleanup; + } continue; } if ((*opts_seen & (1 << i)) && opt->type != VSH_OT_ARGV) { @@ -1119,6 +1127,7 @@ vshCmddefGetOption(vshControl *ctl, const vshCmdDef *cmd, const char *name, cmd->name, name); } cleanup: + VIR_FREE(tmp_name); VIR_FREE(alias); return ret; } -- 1.8.2.1

3 6

[libvirt] [PATCH v2 0/2] Report an error in virPortAllocatorAcquire if all ports are used
by Ján Tomko 14 Nov '13

14 Nov '13

v1: Properly check the return value of virPortAllocatorAcquire https://www.redhat.com/archives/libvir-list/2013-October/msg01239.html v2: Moves the error reporting inside virPortAllocatorAcquire Ján Tomko (2): Add a name to virPortAllocator Return -1 in virPortAllocatorAcquire if all ports are used src/libxl/libxl_conf.c | 5 ----- src/libxl/libxl_driver.c | 3 ++- src/qemu/qemu_driver.c | 9 ++++++--- src/qemu/qemu_migration.c | 16 ++-------------- src/qemu/qemu_process.c | 12 ------------ src/util/virportallocator.c | 16 +++++++++++++--- src/util/virportallocator.h | 3 ++- tests/virportallocatortest.c | 10 ++++------ 8 files changed, 29 insertions(+), 45 deletions(-) -- 1.8.1.5

2 7

[libvirt] [PATCH] virsh-domain: Mark --live and --config mutually exclusive in vcpucount
by Peter Krempa 11 Nov '13

11 Nov '13

The 'vcpucount' command is a getter command for the vCPUu count. When one or more of the filtering flags are specified the command returns the value only for the selected combination. In this case the --live and --config combination isn't valid. This however didn't cause errors as the combination of flags was rejected by the libvirt API but then the fallback code kicked in and requested the count in a way where the clash of the flags didn't matter. Mark the flag combination mutually exclusive so that user's aren't confused. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1024245 --- tools/virsh-domain.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 59e3d8d..60abd3d 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -5331,6 +5331,7 @@ cmdVcpucount(vshControl *ctl, const vshCmd *cmd) if (!maximum && !active && current) current = false; + VSH_EXCLUSIVE_OPTIONS_VAR(live, config) VSH_EXCLUSIVE_OPTIONS_VAR(current, live); VSH_EXCLUSIVE_OPTIONS_VAR(current, config); VSH_EXCLUSIVE_OPTIONS_VAR(active, maximum); -- 1.8.4.2

2 6