- Devel - libvirt List Archives

[libvirt] [PATCHv2 0/4] Introduce APIs to extract DHCP leases info
by Nehal J Wani 13 Sep '13

13 Sep '13

This API returns the information stored in the DHCP leases file created by dnsmasq for a given virtual network. It contacts the bridge network driver, which parses the leases file. It supports two methods: 1. Return info for all network interfaces connected to a given virtual network 2. Return information for a particular network interface in a given virtual network by providing its MAC Address v2 * Since DHCPv6 is supposed to be suported in future, virNetworkGetDHCPLeasesForMAC changed, prefix and virIPAddrType added in virNetworkDHCPLeases struct. v1 * Refer: https://www.redhat.com/archives/libvir-list/2013-September/msg00620.html * The need for these APIs were result of a RFC was proposed on the list. Refer: http://www.redhat.com/archives/libvir-list/2013-July/msg01603.html Nehal J Wani (4): net-dhcp-leases: Implement the public APIs net-dhcp-leases: Implement the remote protocol net-dhcp-leases: Private implementation inside network driver net-dhcp-leases: Add virsh support daemon/remote.c | 133 +++++++++++++++++++++++++++++ include/libvirt/libvirt.h.in | 33 ++++++++ python/generator.py | 3 + src/driver.h | 13 +++ src/libvirt.c | 173 ++++++++++++++++++++++++++++++++++++++ src/libvirt_private.syms | 1 + src/libvirt_public.syms | 7 ++ src/network/bridge_driver.c | 193 +++++++++++++++++++++++++++++++++++++++++++ src/remote/remote_driver.c | 150 +++++++++++++++++++++++++++++++++ src/remote/remote_protocol.x | 50 ++++++++++- src/remote_protocol-structs | 32 +++++++ src/rpc/gendispatch.pl | 1 + tools/virsh-network.c | 101 ++++++++++++++++++++++ tools/virsh.pod | 6 ++ 14 files changed, 895 insertions(+), 1 deletion(-) -- 1.7.11.7

2 10

[libvirt] USB: USB Passthrough Device Autoconnect Feature
by Gonglei (Arei) 13 Sep '13

13 Sep '13

Hi, all Qemu upstream had achieved USB Passthrough Device Autoconnect Feature for the guest. Such as a USB device is unplugged from the host then plugged back in to the same USB physical port. the patch was: https://lists.gnu.org/archive/html/qemu-devel/2011-05/msg02341.html However, Libvirt has not provide such an interface that identifies a USB device for pass through with physical port, rather than the device number. Do you have any ideas or plans about this problem? Thanks in advance. Best Regards, -Gonglei

2 1

[libvirt] rpmbuild libvirt 1.1.2 problem
by jsjshaowentao＠21cn.com 13 Sep '13

13 Sep '13

4 5

[libvirt] [RESEND][PATCHv5 0/4] write separate module for hostdev passthrough
by Chunyan Liu 13 Sep '13

13 Sep '13

[rebased to latest libvirt code for applying and reviewing the patches] These patches implements a separate module for hostdev passthrough so that it could be shared by different drivers and can maintain a global state of a host device. Plus, add passthrough to libxl driver, and change qemu driver and lxc driver to use hostdev common library instead of their own hostdev APIs. --- Changes to v4: * change the way checking hypervisor driver name to decide whether use pciback or pci-stub as stub driver, instead, using driver callback to handle that. * remove get active/inactive list APIs from hostdev common library since currently no code uses them. * add nodedev-detach/reattach/reset to libxl driver * other fixes to Daniel and Jim's comments v4 is here: https://www.redhat.com/archives/libvir-list/2013-August/msg00806.html Changes to v3: * fix Jim's comments v3 is here: https://www.redhat.com/archives/libvir-list/2013-August/msg00019.html Changes to v2: * add patches for qemu driver and lxc driver, use common library APIs instead of their own hostdev APIs. * add APIs for nodedev-detach and nodedev-reattach calling. * rename functions to use unified prefix 'virHostdev' * use VIR_ONCE_GLOBAL_INIT() as others instead of previous Init and Cleanup. * use VIR_STRDUP instead of strdup * rebase to latest code v2 is here: https://www.redhat.com/archives/libvir-list/2013-June/msg00263.html Chunyan Liu (4): add hostdev passthrough common library add pci passthrough to libxl driver change qemu driver to use hostdev common library change lxc driver to use hostdev common library docs/schemas/domaincommon.rng | 1 + po/POTFILES.in | 3 +- src/Makefile.am | 3 +- src/conf/domain_conf.c | 3 +- src/conf/domain_conf.h | 1 + src/libvirt_private.syms | 15 + src/libxl/libxl_conf.c | 63 ++ src/libxl/libxl_conf.h | 4 + src/libxl/libxl_domain.c | 9 + src/libxl/libxl_driver.c | 443 ++++++++++++++- src/lxc/lxc_conf.h | 4 - src/lxc/lxc_driver.c | 45 +- src/lxc/lxc_hostdev.c | 413 ------------- src/lxc/lxc_hostdev.h | 43 -- src/lxc/lxc_process.c | 21 +- src/qemu/qemu_command.c | 1 - src/qemu/qemu_conf.h | 9 +- src/qemu/qemu_domain.c | 9 + src/qemu/qemu_driver.c | 72 +-- src/qemu/qemu_hostdev.c | 1289 --------------------------------------- src/qemu/qemu_hostdev.h | 72 --- src/qemu/qemu_hotplug.c | 126 ++--- src/qemu/qemu_process.c | 34 +- src/util/virhostdev.c | 1335 +++++++++++++++++++++++++++++++++++++++++ src/util/virhostdev.h | 104 ++++ src/util/virpci.c | 28 +- src/util/virpci.h | 9 +- src/util/virscsi.c | 26 +- src/util/virscsi.h | 8 +- src/util/virusb.c | 27 +- src/util/virusb.h | 8 +- 31 files changed, 2195 insertions(+), 2033 deletions(-) delete mode 100644 src/lxc/lxc_hostdev.c delete mode 100644 src/lxc/lxc_hostdev.h delete mode 100644 src/qemu/qemu_hostdev.c delete mode 100644 src/qemu/qemu_hostdev.h create mode 100644 src/util/virhostdev.c create mode 100644 src/util/virhostdev.h

2 2

[libvirt] [PATCH] tools: fix a judgment of equalling zero about an array's length
by lawrancejing 13 Sep '13

13 Sep '13

There is no need to go on executing code when the array's length is zero. --- tools/virsh-snapshot.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/virsh-snapshot.c b/tools/virsh-snapshot.c index e37a5b3..d7a4c7b 100644 --- a/tools/virsh-snapshot.c +++ b/tools/virsh-snapshot.c @@ -239,7 +239,7 @@ vshParseSnapshotMemspec(vshControl *ctl, virBufferPtr buf, const char *str) return 0; narray = vshStringToArray(str, &array); - if (narray < 0) + if (narray <= 0) goto cleanup; for (i = 0; i < narray; i++) { -- 1.7.1

3 2

[libvirt] USB: USB Passthrough Device Autoconnect Feature
by Wangyufei (A) 13 Sep '13

13 Sep '13

Hello, Qemu upstream had achieved USB Passthrough Device Autoconnect Feature for the guest. Such as a USB device is unplugged from the host then plugged back in to the same USB physical port. the patch was: https://lists.gnu.org/archive/html/qemu-devel/2011-05/msg02341.html However, Libvirt has not provided such an interface that identifies a USB device for pass through with physical port, rather than the device number. Do you have any ideas or plans about this problem? Thanks in advance. Best Regards, -WangYufei

1 0

[libvirt] [PATCH v2] Add some notes about security considerations when using LXC
by Daniel P. Berrange 13 Sep '13

13 Sep '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> Describe some of the issues to be aware of when configuring LXC guests with security isolation as a goal. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- docs/drvlxc.html.in | 103 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 103 insertions(+) In v2: - Clarify UNIX domain socket issues wrt filesystem & network namespaces diff --git a/docs/drvlxc.html.in b/docs/drvlxc.html.in index 1e6aa1d..66d97e4 100644 --- a/docs/drvlxc.html.in +++ b/docs/drvlxc.html.in @@ -168,6 +168,109 @@ Further block or character devices will be made available to containers depending on their configuration. </p> +<h2><a name="security">Security considerations</a></h2> + +<p> +The libvirt LXC driver is fairly flexible in how it can be configured, +and as such does not enforce a requirement for strict security +separation between a container and the host. This allows it to be used +in scenarios where only resource control capabilities are important, +and resource sharing is desired. Applications wishing to ensure secure +isolation between a container and the host must ensure that they are +writing a suitable configuration. +</p> + +<h3><a name="securenetworking">Network isolation</a></h3> + +<p> +If the guest configuration does not list any network interfaces, +the <code>network</code> namespace will not be activated, and thus +the container will see all the host's network interfaces. This will +allow apps in the container to bind to/connect from TCP/UDP addresses +and ports from the host OS. It also allows applications to access +UNIX domain sockets associated with the host OS, which are in the +abstract namespace. If access to UNIX domains sockets in the abstract +namespace is not wanted, then applications should set the +<code><privnet/></code> flag in the +<code><features>....</features></code> element. +</p> + +<h3><a name="securefs">Filesystem isolation</a></h3> + +<p> +If the guest configuration does not list any filesystems, then +the container will be set up with a root filesystem that matches +the host's root filesystem. As noted earlier, only a few locations +such as <code>/dev</code>, <code>/proc</code> and <code>/sys</code> +will be altered. This means that, in the absence of restrictions +from sVirt, a process running as user/group N:M inside the container +will be able to access almost exactly the same files as a process +running as user/group N:M in the host. +</p> + +<p> +There are multiple options for restricting this. It is possible to +simply map the existing root filesystem through to the container in +read-only mode. Alternatively a completely separate root filesystem +can be configured for the guest. In both cases, further sub-mounts +can be applied to customize the content that is made visible. Note +that in the absence of sVirt controls, it is still possible for the +root user in a container to unmount any sub-mounts applied. The user +namespace feature can also be used to restrict access to files based +on the UID/GID mappings. +</p> + +<p> +Sharing the host filesystem tree, also allows applications to access +UNIX domains sockets associated with the host OS, which are in the +filesystem namespaces. It should be noted that a number of init +systems including at least <code>systemd</code> and <code>upstart</code> +have UNIX domain socket which are used to control their operation. +Thus, if the directory/filesystem holding their UNIX domain socket is +exposed to the container, it will be possible for a user in the container +to invoke operations on the init service in the same way it could if +outside the container. This also applies to other applications in the +host which use UNIX domain sockets in the filesystem, such as DBus, +Libvirtd, and many more. If this is not desired, then applications +should either specify the UID/GID mapping in the configuration to +enable user namespaces & thus block access to the UNIX domain socket +based on permissions, or should ensure the relevant directories have +a bind mount to hide them. This is particularly important for the +<code>/run</code> or <code>/var/run</code> directories. +</p> + + +<h3><a name="secureusers">User and group isolation</a></h3> + +<p> +If the guest configuration does not list any ID mapping, then the +user and group IDs used inside the container will match those used +outside the container. In addition, the capabilities associated with +a process in the container will infer the same privileges they would +for a process in the host. This has obvious implications for security, +since a root user inside the container will be able to access any +file owned by root that is visible to the container, and perform more +or less any privileged kernel operation. In the absence of additional +protection from sVirt, this means that the root user inside a container +is effectively as powerful as the root user in the host. There is no +security isolation of the root user. +</p> + +<p> +The ID mapping facility was introduced to allow for stricter control +over the privileges of users inside the container. It allows apps to +define rules such as "user ID 0 in the container maps to user ID 1000 +in the host". In addition the privileges associated with capabilities +are somewhat reduced so that they can not be used to escape from the +container environment. A full description of user namespaces is outside +the scope of this document, however LWN has +<a href="https://lwn.net/Articles/532593/">a good write-up on the topic</a>. +From the libvirt point of view, the key thing to remember is that defining +an ID mapping for users and groups in the container XML configuration +causes libvirt to activate the user namespace feature. +</p> + + <h2><a name="activation">Systemd Socket Activation Integration</a></h2> <p> -- 1.8.3.1

3 4

[libvirt] [PATCH] Fix naming of permission for detecting storage pools
by Daniel P. Berrange 13 Sep '13

13 Sep '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> The VIR_ACCESS_PERM_CONNECT_DETECT_STORAGE_POOLS enum constant had its string format be 'detect_storage_pool', note the missing trailing 's'. This prevent the ACL check from ever succeeding. Fix this and add a simple test script to validate this problem of matching names. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- src/Makefile.am | 8 ++++- src/access/viraccessperm.c | 2 +- src/check-aclperms.pl | 75 ++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 83 insertions(+), 2 deletions(-) create mode 100755 src/check-aclperms.pl diff --git a/src/Makefile.am b/src/Makefile.am index 711da32..9f9dcd9 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -528,10 +528,16 @@ check-aclrules: $(REMOTE_PROTOCOL) \ $(addprefix $(srcdir)/,$(filter-out /%,$(STATEFUL_DRIVER_SOURCE_FILES))) +check-aclperms: + $(AM_V_GEN)$(PERL) $(srcdir)/check-aclperms.pl \ + $(srcdir)/access/viraccessperm.h \ + $(srcdir)/access/viraccessperm.c + EXTRA_DIST += check-driverimpls.pl check-aclrules.pl check-local: check-protocol check-symfile check-symsorting \ - check-drivername check-driverimpls check-aclrules + check-drivername check-driverimpls check-aclrules \ + check-aclperms .PHONY: check-protocol $(PROTOCOL_STRUCTS:structs=struct) # Mock driver, covering domains, storage, networks, etc diff --git a/src/access/viraccessperm.c b/src/access/viraccessperm.c index 9c720f9..d517c66 100644 --- a/src/access/viraccessperm.c +++ b/src/access/viraccessperm.c @@ -30,7 +30,7 @@ VIR_ENUM_IMPL(virAccessPermConnect, "search_storage_pools", "search_node_devices", "search_interfaces", "search_secrets", "search_nwfilters", - "detect_storage_pool", "pm_control", + "detect_storage_pools", "pm_control", "interface_transaction"); VIR_ENUM_IMPL(virAccessPermDomain, diff --git a/src/check-aclperms.pl b/src/check-aclperms.pl new file mode 100755 index 0000000..b7fadcd --- /dev/null +++ b/src/check-aclperms.pl @@ -0,0 +1,75 @@ +#!/usr/bin/perl +# +# Copyright (C) 2013 Red Hat, Inc. +# +# This library is free software; you can redistribute it and/or +# modify it under the terms of the GNU Lesser General Public +# License as published by the Free Software Foundation; either +# version 2.1 of the License, or (at your option) any later version. +# +# This library is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +# Lesser General Public License for more details. +# +# You should have received a copy of the GNU Lesser General Public +# License along with this library. If not, see +# <http://www.gnu.org/licenses/>. +# +# This script just validates that the stringified version of +# a virAccessPerm enum matches the enum constant name. We do +# alot of auto-generation of code, so when these don't match +# problems occur, preventing auth from succeeding at all. + +my $hdr = shift; +my $impl = shift; + +my %perms; + +my @perms; + +open HDR, $hdr or die "cannot read $hdr: $!"; + +while (<HDR>) { + if (/^\s+VIR_ACCESS_PERM_([_A-Z]+)(,?|\s|$)/) { + my $perm = $1; + + $perms{$perm} = 1 unless ($perm =~ /_LAST$/); + } +} + +close HDR; + + +open IMPL, $impl or die "cannot read $impl: $!"; + +my $group; +my $warned = 0; + +while (defined (my $line = <IMPL>)) { + if ($line =~ /VIR_ACCESS_PERM_([_A-Z]+)_LAST/) { + $group = $1; + } elsif ($line =~ /"[_a-z]+"/) { + my @bits = split /,/, $line; + foreach my $bit (@bits) { + if ($bit =~ /"([_a-z]+)"/) { + #print $1, "\n"; + + my $perm = uc($group . "_" . $1); + if (!exists $perms{$perm}) { + print STDERR "Unknown perm string $1 for group $group\n"; + $warned = 1; + } + delete $perms{$perm}; + } + } + } +} +close IMPL; + +foreach my $perm (keys %perms) { + print STDERR "Perm $perm had not string form\n"; + $warned = 1; +} + +exit $warned; -- 1.8.3.1

2 2

[libvirt] [PATCH] rbd: Use rbd_create3 to create RBD format 2 images by default
by Wido den Hollander 13 Sep '13

13 Sep '13

This new RBD format supports snapshotting and cloning. By having libvirt create images in format 2 end-users of the created images can benefit of the new RBD format. Signed-off-by: Wido den Hollander <wido(a)widodh.nl> --- src/storage/storage_backend_rbd.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/src/storage/storage_backend_rbd.c b/src/storage/storage_backend_rbd.c index d9e1789..e79873f 100644 --- a/src/storage/storage_backend_rbd.c +++ b/src/storage/storage_backend_rbd.c @@ -435,6 +435,26 @@ cleanup: return ret; } +static int virStorageBackendRBDCreateImage(rados_ioctx_t io, + char *name, long capacity) +{ + int order = 0; + #if LIBRBD_VERSION_CODE > 260 + uint64_t features = 3; + uint64_t stripe_count = 1; + uint64_t stripe_unit = 4194304; + + if (rbd_create3(io, name, capacity, features, &order, + stripe_count, stripe_unit) < 0) { + #else + if (rbd_create(io, name, capacity, &order) < 0) { + #endif + return -1; + } + + return 0; +} + static int virStorageBackendRBDCreateVol(virConnectPtr conn, virStoragePoolObjPtr pool, virStorageVolDefPtr vol) @@ -442,7 +462,6 @@ static int virStorageBackendRBDCreateVol(virConnectPtr conn, virStorageBackendRBDStatePtr ptr; ptr.cluster = NULL; ptr.ioctx = NULL; - int order = 0; int ret = -1; VIR_DEBUG("Creating RBD image %s/%s with size %llu", @@ -467,7 +486,7 @@ static int virStorageBackendRBDCreateVol(virConnectPtr conn, goto cleanup; } - if (rbd_create(ptr.ioctx, vol->name, vol->capacity, &order) < 0) { + if (virStorageBackendRBDCreateImage(ptr.ioctx, vol->name, vol->capacity) < 0) { virReportError(VIR_ERR_INTERNAL_ERROR, _("failed to create volume '%s/%s'"), pool->def->source.name, -- 1.7.9.5

2 2

[libvirt] [PATCH] Allow root users to have their own configuration file
by Martin Kletzander 13 Sep '13

13 Sep '13

Currently, we have two configuration file paths, one global (where "global" means root-only and we're probably not changing this in near future) and one per-user. Unfortunately root user cannot use the second option because until now we were choosing the file path depending only on whether the user is root or not. This patch modifies the mentioned behavior for root only, allowing him to set his own configuration files without changing anything in system-wide configuration folders. This also makes the virsh-uriprecedence test pass its first test case when ran as root. Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- Notes: I'm playing along previously mentioned "proper behavior" in this patch. However, IMNSHO, our "global" or "system-wide" configuration file (defaulting to '/etc/libvirt/libvirt.conf') should be accessible for all users since this has no security impact (security information may be in files 'libvirtd.conf' or 'qemu.conf'). This file should be also read and used for all users. After that, settings in user configuration file (defaulting to '~/.config/libvirt/libvirt.conf') may override some of these settings for that user. This is how all sensible configurations are loaded and that's also what I'd prefer. Unfortunately some developers feels this should be done in completely different way. src/libvirt.c | 56 ++++++++++++++++++++++++++++++++++++-------------------- 1 file changed, 36 insertions(+), 20 deletions(-) diff --git a/src/libvirt.c b/src/libvirt.c index 20a2d4c..bfc466b 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -957,28 +957,34 @@ error: return -1; } -static char * -virConnectGetConfigFilePath(void) +/* + * Return code 0 means no error, but doesn't guarantee path != NULL. + */ +static int +virConnectGetConfigFilePath(char **path, bool global) { - char *path; - if (geteuid() == 0) { - if (virAsprintf(&path, "%s/libvirt/libvirt.conf", + char *userdir = NULL; + int ret = -1; + *path = NULL; + + /* Don't provide the global configuration file to non-root users */ + if (geteuid() != 0 && global) + return 0; + + if (global) { + if (virAsprintf(path, "%s/libvirt/libvirt.conf", SYSCONFDIR) < 0) - return NULL; + goto cleanup; } else { - char *userdir = virGetUserConfigDirectory(); - if (!userdir) - return NULL; - - if (virAsprintf(&path, "%s/libvirt.conf", - userdir) < 0) { - VIR_FREE(userdir); - return NULL; - } - VIR_FREE(userdir); + if (!(userdir = virGetUserConfigDirectory()) || + virAsprintf(path, "%s/libvirt.conf", userdir) < 0) + goto cleanup; } - return path; + ret = 0; + cleanup: + VIR_FREE(userdir); + return ret; } static int @@ -989,12 +995,22 @@ virConnectGetConfigFile(virConfPtr *conf) *conf = NULL; - if (!(filename = virConnectGetConfigFilePath())) + /* Try reading user configuration file unconditionally */ + if (virConnectGetConfigFilePath(&filename, false) < 0) goto cleanup; if (!virFileExists(filename)) { - ret = 0; - goto cleanup; + /* and in case there is none, try the global one. */ + + VIR_FREE(filename); + if (virConnectGetConfigFilePath(&filename, true) < 0) + goto cleanup; + + if (!filename || + !virFileExists(filename)) { + ret = 0; + goto cleanup; + } } VIR_DEBUG("Loading config file '%s'", filename); -- 1.8.3.2

3 6