[libvirt] [PATCH] LXC: add HOME environment variable docs
by Chen Hanxiao
commit
3020594ac57c5e06e79f3db8c765f6bb18c40802
add HOME environment variable.
Add a doc for this.
Signed-off-by: Chen Hanxiao <chenhanxiao(a)cn.fujitsu.com>
---
docs/drvlxc.html.in | 2 ++
1 file changed, 2 insertions(+)
diff --git a/docs/drvlxc.html.in b/docs/drvlxc.html.in
index 403ce24..31da37c 100644
--- a/docs/drvlxc.html.in
+++ b/docs/drvlxc.html.in
@@ -88,6 +88,8 @@ to be provided by all container technologies on Linux.
<dd>The fixed string <code>/bin:/usr/bin</code></dd>
<dt>TERM</dt>
<dd>The fixed string <code>linux</code></dd>
+<dt>HOME</dt>
+<dd>The fixed string <code>/</code></dd>
</dl>
<p>
--
1.9.0
10 years, 2 months
[libvirt] [PATCH v2] Move the FIPS detection from capabilities
by Pavel Hrdina
We are not detecting the presence of FIPS from QEMU, but from procfs and
that means it's not QEMU capability. It was decided that we will pass
this flag to QEMU even if it's not supported by old QEMU binaries.
This patch also reverts changes done by commit a21cfb0f to
qemucapabilitestest and implements a new test case in qemuxml2argvtest.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1135431
Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com>
---
src/qemu/qemu_capabilities.c | 24 ---------------
src/qemu/qemu_command.c | 34 ++++++++++++++++++++--
src/qemu/qemu_command.h | 6 +++-
src/qemu/qemu_driver.c | 3 +-
src/qemu/qemu_process.c | 3 +-
tests/qemucapabilitiesdata/caps_1.2.2-1.caps | 1 -
tests/qemucapabilitiesdata/caps_1.6.0-1.caps | 1 -
tests/qemucapabilitiestest.c | 20 ++++---------
.../qemuxml2argv-fips-enabled.args | 6 ++++
.../qemuxml2argvdata/qemuxml2argv-fips-enabled.xml | 25 ++++++++++++++++
tests/qemuxml2argvtest.c | 9 +++++-
tests/qemuxmlnstest.c | 2 +-
12 files changed, 86 insertions(+), 48 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-fips-enabled.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-fips-enabled.xml
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 9246813..5c3778d 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -3215,30 +3215,6 @@ virQEMUCapsInitQMP(virQEMUCapsPtr qemuCaps,
config.data.nix.path = monpath;
config.data.nix.listen = false;
- /* Qemu 1.2 and later have a binary flag -enable-fips that must be
- * used for VNC auth to obey FIPS settings; but the flag only
- * exists on Linux, and with no way to probe for it via QMP. Our
- * solution: if FIPS mode is required, then unconditionally use
- * the flag, regardless of qemu version, for the following matrix:
- *
- * old QEMU new QEMU
- * FIPS enabled doesn't start VNC auth disabled
- * FIPS disabled/missing VNC auth enabled VNC auth enabled
- *
- * Setting the flag here instead of in virQEMUCapsInitQMPMonitor
- * or virQEMUCapsInitHelp also allows the testsuite to be
- * independent of FIPS setting.
- */
- if (virFileExists("/proc/sys/crypto/fips_enabled")) {
- char *buf = NULL;
-
- if (virFileReadAll("/proc/sys/crypto/fips_enabled", 10, &buf) < 0)
- goto cleanup;
- if (STREQ(buf, "1\n"))
- virQEMUCapsSet(qemuCaps, QEMU_CAPS_ENABLE_FIPS);
- VIR_FREE(buf);
- }
-
VIR_DEBUG("Try to get caps via QMP qemuCaps=%p", qemuCaps);
/*
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index f2e6e5a..911d026 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -3293,6 +3293,35 @@ qemuCheckDiskConfig(virDomainDiskDefPtr disk)
}
+/* Qemu 1.2 and later have a binary flag -enable-fips that must be
+ * used for VNC auth to obey FIPS settings; but the flag only
+ * exists on Linux, and with no way to probe for it via QMP. Our
+ * solution: if FIPS mode is required, then unconditionally use
+ * the flag, regardless of qemu version, for the following matrix:
+ *
+ * old QEMU new QEMU
+ * FIPS enabled doesn't start VNC auth disabled
+ * FIPS disabled/missing VNC auth enabled VNC auth enabled
+ */
+bool
+qemuCheckFips(void)
+{
+ bool ret = false;
+
+ if (virFileExists("/proc/sys/crypto/fips_enabled")) {
+ char *buf = NULL;
+
+ if (virFileReadAll("/proc/sys/crypto/fips_enabled", 10, &buf) < 0)
+ return ret;
+ if (STREQ(buf, "1\n"))
+ ret = true;
+ VIR_FREE(buf);
+ }
+
+ return ret;
+}
+
+
char *
qemuBuildDriveStr(virConnectPtr conn,
virDomainDiskDefPtr disk,
@@ -7543,7 +7572,8 @@ qemuBuildCommandLine(virConnectPtr conn,
virDomainSnapshotObjPtr snapshot,
virNetDevVPortProfileOp vmop,
qemuBuildCommandLineCallbacksPtr callbacks,
- bool standalone)
+ bool standalone,
+ bool enableFips)
{
virErrorPtr originalError = NULL;
size_t i, j;
@@ -7656,7 +7686,7 @@ qemuBuildCommandLine(virConnectPtr conn,
if (!standalone)
virCommandAddArg(cmd, "-S"); /* freeze CPU */
- if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_ENABLE_FIPS))
+ if (enableFips)
virCommandAddArg(cmd, "-enable-fips");
if (qemuBuildMachineArgStr(cmd, def, qemuCaps) < 0)
diff --git a/src/qemu/qemu_command.h b/src/qemu/qemu_command.h
index 633ff71..aa40c9e 100644
--- a/src/qemu/qemu_command.h
+++ b/src/qemu/qemu_command.h
@@ -78,7 +78,8 @@ virCommandPtr qemuBuildCommandLine(virConnectPtr conn,
virDomainSnapshotObjPtr current_snapshot,
virNetDevVPortProfileOp vmop,
qemuBuildCommandLineCallbacksPtr callbacks,
- bool forXMLToArgv)
+ bool forXMLToArgv,
+ bool enableFips)
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(11);
/* Generate '-device' string for chardev device */
@@ -273,4 +274,7 @@ int qemuGetDriveSourceString(virStorageSourcePtr src,
char **source);
int qemuCheckDiskConfig(virDomainDiskDefPtr disk);
+
+bool
+qemuCheckFips(void);
#endif /* __QEMU_COMMAND_H__*/
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 5fd89a3..f1b3348 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -6127,7 +6127,8 @@ static char *qemuConnectDomainXMLToNative(virConnectPtr conn,
NULL, -1, NULL,
VIR_NETDEV_VPORT_PROFILE_OP_NO_OP,
&buildCommandLineCallbacks,
- true)))
+ true,
+ qemuCheckFips())))
goto cleanup;
ret = virCommandToString(cmd);
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 8853d27..40b8576 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -4304,7 +4304,8 @@ int qemuProcessStart(virConnectPtr conn,
if (!(cmd = qemuBuildCommandLine(conn, driver, vm->def, priv->monConfig,
priv->monJSON, priv->qemuCaps,
migrateFrom, stdin_fd, snapshot, vmop,
- &buildCommandLineCallbacks, false)))
+ &buildCommandLineCallbacks, false,
+ qemuCheckFips())))
goto cleanup;
/* now that we know it is about to start call the hook if present */
diff --git a/tests/qemucapabilitiesdata/caps_1.2.2-1.caps b/tests/qemucapabilitiesdata/caps_1.2.2-1.caps
index c8a379a..3b1b699 100644
--- a/tests/qemucapabilitiesdata/caps_1.2.2-1.caps
+++ b/tests/qemucapabilitiesdata/caps_1.2.2-1.caps
@@ -112,7 +112,6 @@
<flag name='usb-storage'/>
<flag name='usb-storage.removable'/>
<flag name='kvm-pit-lost-tick-policy'/>
- <flag name='enable-fips'/>
<flag name='usb-kbd'/>
<flag name='host-pci-multidomain'/>
<flag name='usb-audio'/>
diff --git a/tests/qemucapabilitiesdata/caps_1.6.0-1.caps b/tests/qemucapabilitiesdata/caps_1.6.0-1.caps
index e10f030..21d4320 100644
--- a/tests/qemucapabilitiesdata/caps_1.6.0-1.caps
+++ b/tests/qemucapabilitiesdata/caps_1.6.0-1.caps
@@ -138,7 +138,6 @@
<flag name='boot-strict'/>
<flag name='pvpanic'/>
<flag name='reboot-timeout'/>
- <flag name='enable-fips'/>
<flag name='spice-file-xfer-disable'/>
<flag name='spiceport'/>
<flag name='usb-kbd'/>
diff --git a/tests/qemucapabilitiestest.c b/tests/qemucapabilitiestest.c
index 4e5f9e5..c52ec6c 100644
--- a/tests/qemucapabilitiestest.c
+++ b/tests/qemucapabilitiestest.c
@@ -31,7 +31,6 @@ typedef testQemuData *testQemuDataPtr;
struct _testQemuData {
virDomainXMLOptionPtr xmlopt;
const char *base;
- bool fips;
};
static qemuMonitorTestPtr
@@ -143,12 +142,6 @@ testQemuCaps(const void *opaque)
qemuMonitorTestGetMonitor(mon)) < 0)
goto cleanup;
- /* So that our test does not depend on the contents of /proc, we
- * hoisted the setting of ENABLE_FIPS to virQEMUCapsInitQMP. But
- * we do want to test the effect of that flag. */
- if (data->fips)
- virQEMUCapsSet(capsComputed, QEMU_CAPS_ENABLE_FIPS);
-
if (testQemuCapsCompare(capsProvided, capsComputed) < 0)
goto cleanup;
@@ -183,19 +176,16 @@ mymain(void)
data.xmlopt = xmlopt;
-#define DO_TEST_FULL(name, use_fips) \
- data.base = name; \
- data.fips = use_fips; \
- if (virtTestRun(name, testQemuCaps, &data) < 0) \
+#define DO_TEST(name) \
+ data.base = name; \
+ if (virtTestRun(name, testQemuCaps, &data) < 0) \
ret = -1
-#define DO_TEST(name) DO_TEST_FULL(name, false)
-
- DO_TEST_FULL("caps_1.2.2-1", true);
+ DO_TEST("caps_1.2.2-1");
DO_TEST("caps_1.3.1-1");
DO_TEST("caps_1.4.2-1");
DO_TEST("caps_1.5.3-1");
- DO_TEST_FULL("caps_1.6.0-1", true);
+ DO_TEST("caps_1.6.0-1");
DO_TEST("caps_1.6.50-1");
virObjectUnref(xmlopt);
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-fips-enabled.args b/tests/qemuxml2argvdata/qemuxml2argv-fips-enabled.args
new file mode 100644
index 0000000..196f61f
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-fips-enabled.args
@@ -0,0 +1,6 @@
+LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test QEMU_AUDIO_DRV=none \
+/usr/bin/qemu \
+-S -enable-fips -M pc -m 214 -smp 1 -nographic -monitor \
+unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -usb \
+-hda /dev/HostVG/QEMUGuest1 -net none -serial \
+none -parallel none
diff --git a/tests/qemuxml2argvdata/qemuxml2argv-fips-enabled.xml b/tests/qemuxml2argvdata/qemuxml2argv-fips-enabled.xml
new file mode 100644
index 0000000..a6b041d
--- /dev/null
+++ b/tests/qemuxml2argvdata/qemuxml2argv-fips-enabled.xml
@@ -0,0 +1,25 @@
+<domain type='qemu'>
+ <name>QEMUGuest1</name>
+ <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
+ <memory unit='KiB'>219100</memory>
+ <currentMemory unit='KiB'>219100</currentMemory>
+ <vcpu placement='static' cpuset='1-4,8-20,525'>1</vcpu>
+ <os>
+ <type arch='i686' machine='pc'>hvm</type>
+ <boot dev='hd'/>
+ </os>
+ <clock offset='utc'/>
+ <on_poweroff>destroy</on_poweroff>
+ <on_reboot>restart</on_reboot>
+ <on_crash>destroy</on_crash>
+ <devices>
+ <emulator>/usr/bin/qemu</emulator>
+ <disk type='block' device='disk'>
+ <source dev='/dev/HostVG/QEMUGuest1'/>
+ <target dev='hda' bus='ide'/>
+ <address type='drive' controller='0' bus='0' target='0' unit='0'/>
+ </disk>
+ <controller type='ide' index='0'/>
+ <memballoon model='virtio'/>
+ </devices>
+</domain>
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index 275e699..ab923d0 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -259,6 +259,7 @@ typedef enum {
FLAG_EXPECT_FAILURE = 1 << 1,
FLAG_EXPECT_PARSE_ERROR = 1 << 2,
FLAG_JSON = 1 << 3,
+ FLAG_FIPS = 1 << 4,
} virQemuXML2ArgvTestFlags;
static int testCompareXMLToArgvFiles(const char *xml,
@@ -360,7 +361,8 @@ static int testCompareXMLToArgvFiles(const char *xml,
(flags & FLAG_JSON), extraFlags,
migrateFrom, migrateFd, NULL,
VIR_NETDEV_VPORT_PROFILE_OP_NO_OP,
- &testCallbacks, false))) {
+ &testCallbacks, false,
+ (flags & FLAG_FIPS)))) {
if (!virtTestOOMActive() &&
(flags & FLAG_EXPECT_FAILURE)) {
ret = 0;
@@ -443,6 +445,9 @@ testCompareXMLToArgvHelper(const void *data)
if (virQEMUCapsGet(info->extraFlags, QEMU_CAPS_MONITOR_JSON))
flags |= FLAG_JSON;
+ if (virQEMUCapsGet(info->extraFlags, QEMU_CAPS_ENABLE_FIPS))
+ flags |= FLAG_FIPS;
+
result = testCompareXMLToArgvFiles(xml, args, info->extraFlags,
info->migrateFrom, info->migrateFd,
flags);
@@ -1455,6 +1460,8 @@ mymain(void)
DO_TEST("panic", QEMU_CAPS_DEVICE_PANIC,
QEMU_CAPS_DEVICE, QEMU_CAPS_NODEFCONFIG);
+ DO_TEST("fips-enabled", QEMU_CAPS_ENABLE_FIPS);
+
virObjectUnref(driver.config);
virObjectUnref(driver.caps);
virObjectUnref(driver.xmlopt);
diff --git a/tests/qemuxmlnstest.c b/tests/qemuxmlnstest.c
index e8f70d6..b3a608c 100644
--- a/tests/qemuxmlnstest.c
+++ b/tests/qemuxmlnstest.c
@@ -119,7 +119,7 @@ static int testCompareXMLToArgvFiles(const char *xml,
vmdef, &monitor_chr, json, extraFlags,
migrateFrom, migrateFd, NULL,
VIR_NETDEV_VPORT_PROFILE_OP_NO_OP,
- &testCallbacks, false)))
+ &testCallbacks, false, false)))
goto fail;
if (!virtTestOOMActive()) {
--
1.8.5.5
10 years, 2 months
[libvirt] How do I modify an existing network filter?
by duyahong＠kingsoft.com
Hi All,
We have a requirement to allow more than one IP connect to external network through one mac address. We suppose we need to modify the network filter but we can't find the python API or anything else to change the existing network filter. Does anyone know what I should do?
We tried another way to add a parameter to 'filterref' in the instance xml file like below blue part and it worked. But we have to restart the instance to make this configufation effective. Can I make the xml change effective without restart the instance? Any help will be appreciated.
<interface type='bridge'>
<mac address='fa:16:3e:2f:00:09'/>
<source bridge='br_vm'/>
<model type='virtio'/>
<filterref filter='nova-instance-instance-00000018-fa163e2f0009'>
<parameter name='DHCPSERVER' value='50.1.1.1'/>
<parameter name='IP' value='50.1.1.223'/>
<parameter name='IP' value='50.1.1.222'/>
</filterref>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
duyahong(a)kingsoft.com
10 years, 2 months
[libvirt] [PATCH 1/1] apparmor: use TEMPLATE.qemu for kvm
by Serge Hallyn
virDomainVirtTypeToString() returns 'qemu' and 'kvm' separately.
Don't require a separate apparmor profile for both, rather always
look for TEMPLATE.qemu.
Signed-off-by: Serge Hallyn <serge.hallyn(a)ubuntu.com>
---
src/security/virt-aa-helper.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c
index a06ba44..0447248 100644
--- a/src/security/virt-aa-helper.c
+++ b/src/security/virt-aa-helper.c
@@ -341,15 +341,19 @@ create_profile(const char *profile, const char *profile_name,
int tlen, plen;
int fd;
int rc = -1;
+ const char *virttype;
if (virFileExists(profile)) {
vah_error(NULL, 0, _("profile exists"));
goto end;
}
+ virttype = virDomainVirtTypeToString(virtType);
+ if (strcmp(virttype, "kvm") == 0)
+ virttype = "qemu";
if (virAsprintfQuiet(&template, "%s/TEMPLATE.%s", APPARMOR_DIR "/libvirt",
- virDomainVirtTypeToString(virtType)) < 0) {
+ virttype) < 0) {
vah_error(NULL, 0, _("template name exceeds maximum length"));
goto end;
}
--
2.1.0
10 years, 2 months
[libvirt] [PATCH] Move the FIPS detection from capabilities
by Pavel Hrdina
We are not detecting the presence of FIPS from QEMU, but from procfs and
that means it's not QEMU capability. It was decided that we will pass
this flag to QEMU even if it's not supported by old QEMU binaries.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1135431
Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com>
---
Note: The original bug is that we are not detecting whether libvirtd
binary has been updated, we detect that only for QEMU binary. So you
could update libvirt without updating QEMU and new capabilities that could
already exists in QEMU, but was recently implemented in libvirt wasn't
enabled. I'll post a patch to fix this bug.
src/qemu/qemu_capabilities.c | 24 ------------------------
src/qemu/qemu_command.c | 25 +++++++++++++++++++++++--
2 files changed, 23 insertions(+), 26 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 9246813..5c3778d 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -3215,30 +3215,6 @@ virQEMUCapsInitQMP(virQEMUCapsPtr qemuCaps,
config.data.nix.path = monpath;
config.data.nix.listen = false;
- /* Qemu 1.2 and later have a binary flag -enable-fips that must be
- * used for VNC auth to obey FIPS settings; but the flag only
- * exists on Linux, and with no way to probe for it via QMP. Our
- * solution: if FIPS mode is required, then unconditionally use
- * the flag, regardless of qemu version, for the following matrix:
- *
- * old QEMU new QEMU
- * FIPS enabled doesn't start VNC auth disabled
- * FIPS disabled/missing VNC auth enabled VNC auth enabled
- *
- * Setting the flag here instead of in virQEMUCapsInitQMPMonitor
- * or virQEMUCapsInitHelp also allows the testsuite to be
- * independent of FIPS setting.
- */
- if (virFileExists("/proc/sys/crypto/fips_enabled")) {
- char *buf = NULL;
-
- if (virFileReadAll("/proc/sys/crypto/fips_enabled", 10, &buf) < 0)
- goto cleanup;
- if (STREQ(buf, "1\n"))
- virQEMUCapsSet(qemuCaps, QEMU_CAPS_ENABLE_FIPS);
- VIR_FREE(buf);
- }
-
VIR_DEBUG("Try to get caps via QMP qemuCaps=%p", qemuCaps);
/*
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index f2e6e5a..3532518 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -7656,8 +7656,29 @@ qemuBuildCommandLine(virConnectPtr conn,
if (!standalone)
virCommandAddArg(cmd, "-S"); /* freeze CPU */
- if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_ENABLE_FIPS))
- virCommandAddArg(cmd, "-enable-fips");
+ /* Qemu 1.2 and later have a binary flag -enable-fips that must be
+ * used for VNC auth to obey FIPS settings; but the flag only
+ * exists on Linux, and with no way to probe for it via QMP. Our
+ * solution: if FIPS mode is required, then unconditionally use
+ * the flag, regardless of qemu version, for the following matrix:
+ *
+ * old QEMU new QEMU
+ * FIPS enabled doesn't start VNC auth disabled
+ * FIPS disabled/missing VNC auth enabled VNC auth enabled
+ *
+ * Setting the flag here instead of in virQEMUCapsInitQMPMonitor
+ * or virQEMUCapsInitHelp also allows the testsuite to be
+ * independent of FIPS setting.
+ */
+ if (virFileExists("/proc/sys/crypto/fips_enabled")) {
+ char *buf = NULL;
+
+ if (virFileReadAll("/proc/sys/crypto/fips_enabled", 10, &buf) < 0)
+ goto error;
+ if (STREQ(buf, "1\n"))
+ virCommandAddArg(cmd, "-enable-fips");
+ VIR_FREE(buf);
+ }
if (qemuBuildMachineArgStr(cmd, def, qemuCaps) < 0)
goto error;
--
1.8.5.5
10 years, 2 months
[libvirt] [PATCH] virSecuritySELinuxSetTapFDLabel: Temporarily revert to old behavior
by Michal Privoznik
https://bugzilla.redhat.com/show_bug.cgi?id=1141879
A long time ago I've implemented support for so called multiqueue
net. The idea was to let guest network traffic be processed by
multiple host CPUs and thus increasing performance. However, this
behavior is enabled by QEMU via special ioctl() iterated over the
all tap FDs passed in by libvirt. Unfortunately, SELinux comes in
and disallows the ioctl() call because the /dev/net/tun has label
system_u:object_r:tun_tap_device_t:s0 and 'attach_queue' ioctl()
is not allowed on tun_tap_device_t type. So after discussion with
a SELinux developer we've decided that the FDs passed to the QEMU
should be labelled with svirt_t type and SELinux policy will
allow the ioctl(). Therefore I've made a patch
(cf976d9dcf4e592261b14f03572) that does exactly this. However,
things are not that easy - even though the API to label FD is
called (fsetfilecon_raw) the underlying file is labelled too! So
effectively we are mangling /dev/net/tun label. Yes, that broke
dozen of other application from openvpn, or boxes, to qemu
running other domains.
The best solution would be if SELinux provides a way to label an
FD only, which could be then labeled when passed to the qemu.
However that's a long path to go and we should fix this
regression AQAP. So I went to talk to the SELinux developer again
and we agreed on temporary solution that:
1) my patch is reverted
2) SELinux temporarily allows 'attach_queue' on the
tun_tap_device_t
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/security/security_selinux.c | 36 +++++++++++++++++++++++++++++++++---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c
index 3db2b27..c69eeb9 100644
--- a/src/security/security_selinux.c
+++ b/src/security/security_selinux.c
@@ -2343,17 +2343,47 @@ virSecuritySELinuxSetImageFDLabel(virSecurityManagerPtr mgr ATTRIBUTE_UNUSED,
}
static int
-virSecuritySELinuxSetTapFDLabel(virSecurityManagerPtr mgr ATTRIBUTE_UNUSED,
+virSecuritySELinuxSetTapFDLabel(virSecurityManagerPtr mgr,
virDomainDefPtr def,
int fd)
{
+ struct stat buf;
+ security_context_t fcon = NULL;
virSecurityLabelDefPtr secdef;
+ char *str = NULL;
+ int rc = -1;
secdef = virDomainDefGetSecurityLabelDef(def, SECURITY_SELINUX_NAME);
- if (!secdef || !secdef->imagelabel)
+ if (!secdef || !secdef->label)
return 0;
- return virSecuritySELinuxFSetFilecon(fd, secdef->imagelabel);
+ if (fstat(fd, &buf) < 0) {
+ virReportSystemError(errno, _("cannot stat tap fd %d"), fd);
+ goto cleanup;
+ }
+
+ if ((buf.st_mode & S_IFMT) != S_IFCHR) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("tap fd %d is not character device"), fd);
+ goto cleanup;
+ }
+
+ if (getContext(mgr, "/dev/tap.*", buf.st_mode, &fcon) < 0) {
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("cannot lookup default selinux label for tap fd %d"), fd);
+ goto cleanup;
+ }
+
+ if (!(str = virSecuritySELinuxContextAddRange(secdef->label, fcon))) {
+ goto cleanup;
+ } else {
+ rc = virSecuritySELinuxFSetFilecon(fd, str);
+ }
+
+ cleanup:
+ freecon(fcon);
+ VIR_FREE(str);
+ return rc;
}
static char *
--
1.8.5.5
10 years, 2 months
Re: [libvirt] [virt-tools-list] [PATCH virt-manager] details: Add UI for enabling UEFI via 'customize before install'
by Eric Blake
[adding libvirt]
On 09/18/2014 06:28 AM, Cole Robinson wrote:
> - Say you are connecting from a new libvirt UNDEFINE_NVRAM support (say Fedora
> 21 GA), to an old libvirt without it, like F20 or RHEL7.0. If we specify the
> flag unconditionally, the undefineFlags call will fail, which also means that
> we lose the benefit of the other UNDEFINE flags. So if the VM had managedsave
> data, the undefine will fail saying we need to remove it first.
>
> - Not all drivers support the UNDEFINE_NVRAM flag, like the 'test' driver
> which we use heavily for virt-manager development. If we pass the flag
> unconditionally, then the current code loses the benefit of all UNDEFINE
> flags, and trying to delete a VM with managedsave data will fail.
>
> The existing code has similar problems as well though, since we lump all the
> UNDEFINE flags together, so it certainly isn't perfect. However my hack of
> checking for nvram in the XML avoids some of the common issues, so I'll extend
> it with the logic you pointed out.
>
> Trying to figure out if an API or flag is supported with an arbitrary libvirt
> connection is a pain: it's a factor of host libvirt version, host
> libvirt-python version, remote libvirt version, libvirt hv driver, hv version.
> Some readonly APIs you can get away with just testing first, but undefine
> isn't one of them :) Maybe we can get a libvirt API exposing the driver
> function table at least?
Hmm, I've been thinking about that too. It would indeed be nice to
introspect what APIs are available, and for those APIs with a flags
parameter, what flag(s) bits are supported. What signature would we
want? Thinking aloud here...
Maybe:
struct virAPI {
const char *name; /* Name of the C API call */
unsigned int flags; /* The flag bits that are understood, if the
C API includes a flags argument */
};
/* Allocate a list of supported API information into *list, and return
the length of the list. User must call free() on the array when done.
flags is 0 for now */
int virConnectListAPI(virConnectPtr conn, virAPIPtr *list,
unsigned int flags);
Or even having an enum mapping of C API names, instead of passing around
char*. But the enum would not quite match the RPC call numbers.
Implementation-wise, we've got a lot of driver calls that manually call
virCheckFlags() at the front; maybe what we would do is modify the
driver.h callback list to have a struct that contains both a callback
pointer AND a flags value, rather than the current use of just a
callback pointer; then we can make the rejection of unsupported flags in
common code instead of manual virCheckFlags() everywhere, and we could
also use the population of that registration as our point of
documentation for when support for given bits in the flags argument is
added.
There's still the question of how dynamic this can be - for example,
some qemu driver APIs accept a flag in name, but then fail if the
underlying qemu binary is too old. Is it sufficient to document that
the API knows about the flag, or do we really want the more complex
solution of getting the exact subset of flags that have a chance of
succeeding based on the underlying qemu binary? I'm leaning towards
having the introspection API just report a flag if the driver plans on
handling it; and in the cases where the underlying binary can cause the
flag to succeed or fail, we can then use virConnectGetDomainCapabilities
to advertise that sort of runtime difference (in other words, the API
I'm thinking about adding is static and won't change answers based on a
qemu upgrade; anything that depends on the actual running qemu affects
is reflected through existing API).
What about APIs that accept more than just a flags argument, such as the
recent virConnectGetAllDomainStats, which as both a stats and flags
parameter? Should the virAPI return struct contain a virTypedParameters
or similar thing that can let us describe multiple details about a given
API?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
10 years, 2 months
[libvirt] [PATCH] qemu_capabilities: fix issue with discarding old capabilities
by Pavel Hrdina
There was a bug that if libvirtd binary has been updated than the
capability file wasn't reloaded therefore new capabilities introduced
in libvirt cannot be used because the cached version was loaded.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1135431
Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com>
---
src/qemu/qemu_capabilities.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 81ada48..dae89aa 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -286,6 +286,7 @@ struct _virQEMUCaps {
char *binary;
time_t ctime;
+ time_t selfctime;
virBitmapPtr flags;
@@ -2689,7 +2690,7 @@ virQEMUCapsSaveCache(virQEMUCapsPtr qemuCaps, const char *filename)
virBufferAsprintf(&buf, "<qemuctime>%llu</qemuctime>\n",
(long long)qemuCaps->ctime);
virBufferAsprintf(&buf, "<selfctime>%llu</selfctime>\n",
- (long long)virGetSelfLastChanged());
+ (long long)qemuCaps->selfctime);
if (qemuCaps->usedQMP)
virBufferAddLit(&buf, "<usedQMP/>\n");
@@ -2743,7 +2744,7 @@ virQEMUCapsSaveCache(virQEMUCapsPtr qemuCaps, const char *filename)
VIR_DEBUG("Saved caps '%s' for '%s' with (%lld, %lld)",
filename, qemuCaps->binary,
(long long)qemuCaps->ctime,
- (long long)virGetSelfLastChanged());
+ (long long)qemuCaps->selfctime);
ret = 0;
cleanup:
@@ -2871,12 +2872,12 @@ virQEMUCapsInitCached(virQEMUCapsPtr qemuCaps, const char *cacheDir)
/* Discard if cache is older that QEMU binary */
if (qemuctime != qemuCaps->ctime ||
- selfctime < virGetSelfLastChanged()) {
+ selfctime < qemuCaps->selfctime) {
VIR_DEBUG("Outdated cached capabilities '%s' for '%s' "
"(%lld vs %lld, %lld vs %lld)",
capsfile, qemuCaps->binary,
(long long)qemuctime, (long long)qemuCaps->ctime,
- (long long)selfctime, (long long)virGetSelfLastChanged());
+ (long long)selfctime, (long long)qemuCaps->selfctime);
ignore_value(unlink(capsfile));
virQEMUCapsReset(qemuCaps);
ret = 0;
@@ -3371,6 +3372,7 @@ virQEMUCapsPtr virQEMUCapsNewForBinary(const char *binary,
goto error;
}
qemuCaps->ctime = sb.st_ctime;
+ qemuCaps->selfctime = virGetSelfLastChanged();
/* Make sure the binary we are about to try exec'ing exists.
* Technically we could catch the exec() failure, but that's
@@ -3420,7 +3422,8 @@ bool virQEMUCapsIsValid(virQEMUCapsPtr qemuCaps)
if (stat(qemuCaps->binary, &sb) < 0)
return false;
- return sb.st_ctime == qemuCaps->ctime;
+ return sb.st_ctime == qemuCaps->ctime &&
+ virGetSelfLastChanged() >= qemuCaps->selfctime;
}
--
1.8.5.5
10 years, 2 months
[libvirt] LSN-2014-0004: Querying blkiotune after disk hotplug can lead to libvirtd crash
by Daniel P. Berrange
Libvirt Security Notice: LSN-2014-0004
======================================
Summary: Querying blkiotune after disk hotplug can lead to
libvirtd crash
Reported on: 20140911
Published on: 20140917
Fixed on: 20140917
Reported by: Luyao Huang <lhuang(a)redhat.com>
Patched by: Peter Krempa <pkrempa(a)redhat.com>
See also: CVE-2014-3633
Description
-----------
The qemu implementation of virDomainGetBlockIoTune computed an index
into the array of disks for the live definition, then used it as the
index into the array of disks for the persistent definition. If
management had hot-plugged disks to the live definition, the two
arrays are not necessarily the same length, and this could result in
the persistent definition dereferencing an out-of-bounds pointer.
Impact
------
A read-only client can cause a denial of service attack against a
privileged client if the out-of-bounds dereference causes libvirtd
to crash, or possibly gain read access to sensitive information
residing in the heap.
Workaround
----------
The out-of-bounds access is only possible on domains that have had
disks hot-plugged or removed from the live image without also
updating the persistent definition to match; keeping the two
definitions matched or using only transient domains will avoid the
problem. Denying access to the readonly libvirt socket will avoid
the potential for a denial of service attack, but will not prevent
the out-of-bounds access from causing a crash for a privileged
client, although such a crash is no longer a security problem.
Affected product
----------------
Name: libvirt
Repository: git://libvirt.org/git/libvirt.git
http://libvirt.org/git/?p=libvirt.git
Branch: master
Broken in: v0.9.8
Broken in: v0.9.9
Broken in: v0.9.10
Broken in: v0.9.11
Broken in: v0.9.12
Broken in: v0.9.13
Broken in: v1.0.0
Broken in: v1.0.1
Broken in: v1.0.2
Broken in: v1.0.3
Broken in: v1.0.4
Broken in: v1.0.5
Broken in: v1.0.6
Broken in: v1.1.0
Broken in: v1.1.1
Broken in: v1.1.2
Broken in: v1.1.3
Broken in: v1.1.4
Broken in: v1.2.0
Broken in: v1.2.1
Broken in: v1.2.2
Broken in: v1.2.3
Broken in: v1.2.4
Broken in: v1.2.5
Broken in: v1.2.6
Broken in: v1.2.7
Broken in: v1.2.8
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: 3e745e8f775dfe6f64f18b5c2fe4791b35d3546b
Branch: v0.9.11-maint
Broken in: v0.9.11.1
Broken in: v0.9.11.2
Broken in: v0.9.11.3
Broken in: v0.9.11.4
Broken in: v0.9.11.5
Broken in: v0.9.11.6
Broken in: v0.9.11.7
Broken in: v0.9.11.8
Broken in: v0.9.11.9
Broken in: v0.9.11.10
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Branch: v0.9.12-maint
Broken in: v0.9.12.1
Broken in: v0.9.12.2
Broken in: v0.9.12.3
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: 750280023cc0896b05f86e292857ceef5eee3a72
Branch: v0.10.2-maint
Broken in: v0.10.2.1
Broken in: v0.10.2.2
Broken in: v0.10.2.3
Broken in: v0.10.2.4
Broken in: v0.10.2.5
Broken in: v0.10.2.6
Broken in: v0.10.2.7
Broken in: v0.10.2.8
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: 0fa54204f264e3d39387f5762f810d31cce770b2
Branch: v1.0.2-maint
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: d30fea03a545a2d9f5f228cd3292484ce7850256
Branch: v1.0.3-maint
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: 35a802639d713054503f7243e39be0503fe19ec3
Branch: v1.0.4-maint
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: a45c8466fa3531d35728575a1facc0406f97079a
Branch: v1.0.5-maint
Broken in: v1.0.5.1
Broken in: v1.0.5.2
Broken in: v1.0.5.3
Broken in: v1.0.5.4
Broken in: v1.0.5.5
Broken in: v1.0.5.6
Broken in: v1.0.5.7
Broken in: v1.0.5.8
Broken in: v1.0.5.9
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: cc05c6d5d2f7a577a1a365fbc5451fb6b5f57445
Branch: v1.0.6-maint
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: cc19d1c08f49acdcfd5eb0e26561ea88e800f177
Branch: v1.1.0-maint
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: dd8a348e4747a59c60991f3b41567ab0a1dcca0e
Branch: v1.1.1-maint
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: ed071fee073bc5a439ec64f0e501d5f90c41dec5
Branch: v1.1.2-maint
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: d4360edd1ca88cb1f144bf77f7df23ebf1f90632
Branch: v1.1.3-maint
Broken in: v1.1.3.1
Broken in: v1.1.3.2
Broken in: v1.1.3.3
Broken in: v1.1.3.4
Broken in: v1.1.3.5
Broken in: v1.1.3.6
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: eefe2e013820a76dfe5132431db72aade911eeab
Branch: v1.1.4-maint
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: 92430a6942fc0f4dceea4957f688430f093676ab
Branch: v1.2.0-maint
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: e8f6971e3f29a7392224d7056b05b2acf133e58d
Branch: v1.2.1-maint
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: fdde9d6a1b8a559f5fa18a68cc8e8a35354b3ae9
Branch: v1.2.2-maint
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: 111855e82429249ccd98f9ed0c8c72116e241959
Branch: v1.2.3-maint
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: 81edcbb3ca1061d5b54945a7e1e9e2e03891307b
Branch: v1.2.4-maint
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: 8a07faf3377c4b1e9f4ded59882f305426d02e6c
Branch: v1.2.5-maint
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: 7156bd0ce2dc92231c393fc7bd493e7aa383d966
Branch: v1.2.6-maint
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: 4e701c06c54ec007041e20e5ef085711f38a0266
Branch: v1.2.7-maint
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: cf7a69bc08e79c254f1accd939f4746ca94fe7e7
Branch: v1.2.8-maint
Broken by: eca96694a7f992be633d48d5ca03cedc9bbc3c9aa
Fixed by: 6bdf14150e99ca8921a4017bb9502325e200815b
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
10 years, 2 months
[libvirt] [PATCH] docs: update zfs documentation
by Roman Bogorodskiy
- docs/formatstorage.html.in: document 'zfs' pool type, add it
to a list of pool types that could use source physical devices
- docs/storage.html.in: update a ZFS pool example XML with
source physical devices, mention that starting from 1.2.9 a
pool could be created from this devices by libvirt and in earlier
versions user still has to create a pool manually
- docs/drvbhyve.html.in: add an example with ZFS pools
---
docs/drvbhyve.html.in | 16 ++++++++++++++++
docs/formatstorage.html.in | 7 ++++---
docs/storage.html.in | 18 ++++++++++++------
3 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/docs/drvbhyve.html.in b/docs/drvbhyve.html.in
index 71e3bc4..39afdf5 100644
--- a/docs/drvbhyve.html.in
+++ b/docs/drvbhyve.html.in
@@ -141,5 +141,21 @@ tweak them.</p>
/usr/sbin/bhyve -c 2 -m 214 -A -I -H -P -s 0:0,hostbridge -s 3:0,virtio-net,tap0,mac=52:54:00:5d:74:e3 -s 2:0,virtio-blk,/home/user/vm1.img -s 1,lpc -l com1,/dev/nmdm0A vm1
</pre>
+<h3><a name="zfsvolume">Using ZFS volumes</a></h3>
+
+<p>It's possible to use ZFS volumes as disk devices <span class="since">since 1.2.8</span>.
+An example of domain XML device entry for that will look like:</p>
+
+<pre>
+ ...
+ <disk type='volume' device='disk'>
+ <source pool='zfspool' volume='vol1'/>
+ <target dev='vdb' bus='virtio'/>
+ </disk>
+ ...</pre>
+
+<p>Please refer to the <a href="storage.html">Storage documentation</a> for more details on storage
+management.</p>
+
</body>
</html>
diff --git a/docs/formatstorage.html.in b/docs/formatstorage.html.in
index e25bba7..d3e6f05 100644
--- a/docs/formatstorage.html.in
+++ b/docs/formatstorage.html.in
@@ -23,8 +23,9 @@
(<span class="since">since 0.7.1</span>), <code>rbd</code>
(<span class="since">since 0.9.13</span>), <code>sheepdog</code>
(<span class="since">since 0.10.0</span>),
- or <code>gluster</code> (<span class="since">since
- 1.2.0</span>). This corresponds to the
+ <code>gluster</code> (<span class="since">since
+ 1.2.0</span>) or <code>zfs</code> (<span class="since">since
+ 1.2.8</span>). This corresponds to the
storage backend drivers listed further along in this document.
</p>
<h3><a name="StoragePoolFirst">General metadata</a></h3>
@@ -115,7 +116,7 @@
<dt><code>device</code></dt>
<dd>Provides the source for pools backed by physical devices
(pool types <code>fs</code>, <code>logical</code>, <code>disk</code>,
- <code>iscsi</code>).
+ <code>iscsi</code>, <code>zfs</code>).
May be repeated multiple times depending on backend driver. Contains
a single attribute <code>path</code> which is the fully qualified
path to the block device node. <span class="since">Since 0.4.1</span></dd>
diff --git a/docs/storage.html.in b/docs/storage.html.in
index 5db79c7..3d2ffca 100644
--- a/docs/storage.html.in
+++ b/docs/storage.html.in
@@ -750,22 +750,28 @@
<p>
This provides a pool based on the ZFS filesystem. It is currently
supported on FreeBSD only.
+ </p>
- A pool has to be created before libvirt could start using it. That
- could be done using <code>zpool create</code> command. Please refer to
- the ZFS documentation for details on a pool creation.
-
- <span class="since">Since 1.2.8</span>
+ <p>A pool could either be created manually using the <code>zpool create</code>
+ command and its name specified in the source section or <span class="since">
+ since 1.2.9</span> source devices could be specified to create a pool using
+ libvirt.
</p>
+ <p>Please refer to the ZFS documentation for details on a pool creation.</p>
+
+ <p><span class="since">Since 1.2.8</span></p>.
+
<h3>Example pool input</h3>
<pre>
<pool type="zfs">
<name>myzfspool</name>
<source>
<name>zpoolname</name>
+ <device path="/dev/ada1"/>
+ <device path="/dev/ada2"/>
</source>
- </pool></pre>
+ </pool></pre>
<h3>Valid pool format types</h3>
<p>
--
2.0.2
10 years, 2 months
