[libvirt] [PATCH] qemu: keep capabilities when running QEMU as root
by Daniel P. Berrangé
When QEMU uid/gid is set to non-root this is pointless as if we just
used a regular setuid/setgid call, the process will have all its
capabilities cleared anyway by the kernel.
When QEMU uid/gid is set to root, this is almost (always?) never
what people actually want. People make QEMU run as root in order
to access some privileged resource that libvirt doesn't support
yet and this often requires capabilities. As a result they have
to go find the qemu.conf param to turn this off. This is not
viable for libguestfs - they want to control everything via the
XML security label to request running as root regardless of the
qemu.conf settings for user/group.
Clearing capabilities was implemented originally because there
was a proposal in Fedora to change permissions such that root,
with no capabilities would not be able to compromise the system.
ie a locked down root account. This never went anywhere though,
and as a result clearing capabilities when running as root does
not really get us any security benefit AFAICT. The root user
can easily do something like create a cronjob, which will then
faithfully be run with full capabilities, trivially bypassing
the restriction we place.
IOW, our clearing of capabilities is both useless from a security
POV, and breaks valid use cases when people need to run as root.
This removes the clear_emulator_capabilities configuration
option from qemu.conf, and always runs QEMU with capabilities
when root. The behaviour when non-root is unchanged.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
docs/drvqemu.html.in | 46 +++++++++++-------------------
src/qemu/libvirtd_qemu.aug | 8 +++++-
src/qemu/qemu.conf | 11 -------
src/qemu/qemu_conf.c | 4 ---
src/qemu/qemu_conf.h | 1 -
src/qemu/qemu_domain.c | 3 +-
src/qemu/qemu_process.c | 5 ----
src/qemu/test_libvirtd_qemu.aug.in | 1 -
8 files changed, 25 insertions(+), 54 deletions(-)
diff --git a/docs/drvqemu.html.in b/docs/drvqemu.html.in
index 294117ee1f..8beb28655c 100644
--- a/docs/drvqemu.html.in
+++ b/docs/drvqemu.html.in
@@ -187,41 +187,29 @@ chmod o+x /path/to/directory
</li>
</ul>
- <h3><a id="securitycap">Linux process capabilities</a></h3>
-
<p>
- The libvirt QEMU driver has a build time option allowing it to use
- the <a href="http://people.redhat.com/sgrubb/libcap-ng/index.html">libcap-ng</a>
- library to manage process capabilities. If this build option is
- enabled, then the QEMU driver will use this to ensure that all
- process capabilities are dropped before executing a QEMU virtual
- machine. Process capabilities are what gives the 'root' account
- its high power, in particular the CAP_DAC_OVERRIDE capability
- is what allows a process running as 'root' to access files owned
- by any user.
+ The libvirt maintainers <strong>strongly recommend against</strong>
+ running QEMU as the root user/group. This should not be required
+ in most supported usage scenarios, as libvirt will generally do the
+ right thing to grant QEMU access to files it is permitted to
+ use when it is running non-root.
</p>
+ <h3><a id="securitycap">Linux process capabilities</a></h3>
+
<p>
- If the QEMU driver is configured to run virtual machines as non-root,
- then they will already lose all their process capabilities at time
- of startup. The Linux capability feature is thus aimed primarily at
- the scenario where the QEMU processes are running as root. In this
- case, before launching a QEMU virtual machine, libvirtd will use
- libcap-ng APIs to drop all process capabilities. It is important
- for administrators to note that this implies the QEMU process will
- <strong>only</strong> be able to access files owned by root, and
- not files owned by any other user.
+ In versions of libvirt prior to 6.0.0, even if QEMU was configured
+ to run as the root user / group, libvirt would strip all process
+ capabilities. This meant that QEMU could only read/write files
+ owned by root, or with open permissions. In reality, stripping
+ capabilities did not have any security benefit, as it was trivial
+ to get commands to run in another context with full capabilities,
+ for example, by creating a cronjob.
</p>
-
<p>
- Thus, if a vendor / distributor has configured their libvirt package
- to run as 'qemu' by default, a number of changes will be required
- before an administrator can change a host to run guests as root.
- In particular it will be necessary to change ownership on the
- directories <code>/var/run/libvirt/qemu/</code>,
- <code>/var/lib/libvirt/qemu/</code> and
- <code>/var/cache/libvirt/qemu/</code> back to root, in addition
- to changing the <code>/etc/libvirt/qemu.conf</code> settings.
+ Thus since 6.0.0, if QEMU is running as root, it will keep all
+ process capabilities. Behaviour when QEMU is running non-root
+ is unchanged, it still has no capabilities.
</p>
<h3><a id="securityselinux">SELinux basic confinement</a></h3>
diff --git a/src/qemu/libvirtd_qemu.aug b/src/qemu/libvirtd_qemu.aug
index 7d7844dc09..86bea2a32a 100644
--- a/src/qemu/libvirtd_qemu.aug
+++ b/src/qemu/libvirtd_qemu.aug
@@ -86,7 +86,6 @@ module Libvirtd_qemu =
| bool_entry "auto_start_bypass_cache"
let process_entry = str_entry "hugetlbfs_mount"
- | bool_entry "clear_emulator_capabilities"
| str_entry "bridge_helper"
| str_entry "pr_helper"
| str_entry "slirp_helper"
@@ -129,6 +128,12 @@ module Libvirtd_qemu =
let swtpm_entry = str_entry "swtpm_user"
| str_entry "swtpm_group"
+ (* Entries that used to exist in the config which are now
+ * deleted. We keep on parsing them so we don't break
+ * ability to parse old configs after upgrade
+ *)
+ let obsolete_entry = bool_entry "clear_emulator_capabilities"
+
let capability_filters_entry = str_array_entry "capability_filters"
(* Each entry in the config is one of the following ... *)
@@ -153,6 +158,7 @@ module Libvirtd_qemu =
| nbd_entry
| swtpm_entry
| capability_filters_entry
+ | obsolete_entry
let comment = [ label "#comment" . del /#[ \t]*/ "# " . store /([^ \t\n][^\n]*)?/ . del /\n/ "\n" ]
let empty = [ label "#empty" . eol ]
diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
index 7a056b037e..b6805ffc41 100644
--- a/src/qemu/qemu.conf
+++ b/src/qemu/qemu.conf
@@ -583,17 +583,6 @@
#bridge_helper = "/usr/libexec/qemu-bridge-helper"
-
-# If clear_emulator_capabilities is enabled, libvirt will drop all
-# privileged capabilities of the QEMU/KVM emulator. This is enabled by
-# default.
-#
-# Warning: Disabling this option means that a compromised guest can
-# exploit the privileges and possibly do damage to the host.
-#
-#clear_emulator_capabilities = 1
-
-
# If enabled, libvirt will have QEMU set its process name to
# "qemu:VM_NAME", where VM_NAME is the name of the VM. The QEMU
# process will appear as "qemu:VM_NAME" in process listings and
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 30637b21ac..0e14d60bc9 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -234,8 +234,6 @@ virQEMUDriverConfigPtr virQEMUDriverConfigNew(bool privileged)
cfg->prHelperName = g_strdup(QEMU_PR_HELPER);
cfg->slirpHelperName = g_strdup(QEMU_SLIRP_HELPER);
- cfg->clearEmulatorCapabilities = true;
-
cfg->securityDefaultConfined = true;
cfg->securityRequireConfined = false;
@@ -602,8 +600,6 @@ virQEMUDriverConfigLoadProcessEntry(virQEMUDriverConfigPtr cfg,
}
}
- if (virConfGetValueBool(conf, "clear_emulator_capabilities", &cfg->clearEmulatorCapabilities) < 0)
- return -1;
if (virConfGetValueString(conf, "bridge_helper", &cfg->bridgeHelperName) < 0)
return -1;
diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h
index 95b33a1093..a641bbd983 100644
--- a/src/qemu/qemu_conf.h
+++ b/src/qemu/qemu_conf.h
@@ -161,7 +161,6 @@ struct _virQEMUDriverConfig {
bool relaxedACS;
bool vncAllowHostAudio;
bool nogfxAllowHostAudio;
- bool clearEmulatorCapabilities;
bool setProcessName;
unsigned int maxProcesses;
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 470d342afc..0dadca4894 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -9345,8 +9345,7 @@ void qemuDomainObjCheckTaint(virQEMUDriverPtr driver,
bool custom_hypervisor_feat = false;
if (virQEMUDriverIsPrivileged(driver) &&
- (!cfg->clearEmulatorCapabilities ||
- cfg->user == 0 ||
+ (cfg->user == 0 ||
cfg->group == 0))
qemuDomainObjTaint(driver, obj, VIR_DOMAIN_TAINT_HIGH_PRIVILEGES, logCtxt);
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 75ee3893c6..979ea36f0f 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -6811,11 +6811,6 @@ qemuProcessLaunch(virConnectPtr conn,
if (qemuDomainCreateNamespace(driver, vm) < 0)
goto cleanup;
- VIR_DEBUG("Clear emulator capabilities: %d",
- cfg->clearEmulatorCapabilities);
- if (cfg->clearEmulatorCapabilities)
- virCommandClearCaps(cmd);
-
VIR_DEBUG("Setting up raw IO");
if (qemuProcessSetupRawIO(driver, vm, cmd) < 0)
goto cleanup;
diff --git a/src/qemu/test_libvirtd_qemu.aug.in b/src/qemu/test_libvirtd_qemu.aug.in
index b9cf8d6688..dd90edf687 100644
--- a/src/qemu/test_libvirtd_qemu.aug.in
+++ b/src/qemu/test_libvirtd_qemu.aug.in
@@ -72,7 +72,6 @@ module Test_libvirtd_qemu =
{ "auto_start_bypass_cache" = "0" }
{ "hugetlbfs_mount" = "/dev/hugepages" }
{ "bridge_helper" = "/usr/libexec/qemu-bridge-helper" }
-{ "clear_emulator_capabilities" = "1" }
{ "set_process_name" = "1" }
{ "max_processes" = "0" }
{ "max_files" = "0" }
--
2.21.0
5 years
[libvirt] [jenkins-ci PATCH v2 0/3] Enable building of the VZ driver on CentOS 7
by Daniel P. Berrangé
The VZ driver in libvirt periodically gets broken by refactoring in
libvirt. This is not noticed either before or after merge because none
of our CI tests nor common developer build hosts includ the deps needed
for the VZ driver.
The OpenVZ project, however, does provide builds of the required
packages for RHEL-7. We can use these packages in our CentOS 7 CI VMs to
enable build testing of the VZ driver. This closes the only hole we have
in driver build coverage for CI.
Changed in v2:
- Enable GPG verification
- Use older repo avoid temporary deps problem
- Setup repos in dockerfile too.
Daniel P. Berrangé (3):
guests: add openvz repository on CentOS 7
guests: define mapping for the libprlsdk package
guests: add libprlsdk package to libvirt project
guests/lcitool | 22 ++++++++++++++++
guests/playbooks/update/tasks/base.yml | 25 +++++++++++++++++++
guests/playbooks/update/templates/openvz.key | 20 +++++++++++++++
.../playbooks/update/templates/openvz.repo.j2 | 9 +++++++
guests/vars/mappings.yml | 4 +++
guests/vars/projects/libvirt.yml | 1 +
6 files changed, 81 insertions(+)
create mode 100644 guests/playbooks/update/templates/openvz.key
create mode 100644 guests/playbooks/update/templates/openvz.repo.j2
--
2.23.0
5 years
[libvirt] [dockerfiles PATCH] Rename Ubuntu Dockerfiles
by Andrea Bolognani
The corresponding libvirt-jenkins-ci commit is f289e64a5fd9.
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
Pushed as trivial.
...ntu-16.zip => buildenv-libosinfo-ubuntu-1604.zip | Bin
...ntu-18.zip => buildenv-libosinfo-ubuntu-1804.zip | Bin
...buntu-16.zip => buildenv-libvirt-ubuntu-1604.zip | Bin
...buntu-18.zip => buildenv-libvirt-ubuntu-1804.zip | Bin
4 files changed, 0 insertions(+), 0 deletions(-)
rename buildenv-libosinfo-ubuntu-16.zip => buildenv-libosinfo-ubuntu-1604.zip (100%)
rename buildenv-libosinfo-ubuntu-18.zip => buildenv-libosinfo-ubuntu-1804.zip (100%)
rename buildenv-libvirt-ubuntu-16.zip => buildenv-libvirt-ubuntu-1604.zip (100%)
rename buildenv-libvirt-ubuntu-18.zip => buildenv-libvirt-ubuntu-1804.zip (100%)
diff --git a/buildenv-libosinfo-ubuntu-16.zip b/buildenv-libosinfo-ubuntu-1604.zip
similarity index 100%
rename from buildenv-libosinfo-ubuntu-16.zip
rename to buildenv-libosinfo-ubuntu-1604.zip
diff --git a/buildenv-libosinfo-ubuntu-18.zip b/buildenv-libosinfo-ubuntu-1804.zip
similarity index 100%
rename from buildenv-libosinfo-ubuntu-18.zip
rename to buildenv-libosinfo-ubuntu-1804.zip
diff --git a/buildenv-libvirt-ubuntu-16.zip b/buildenv-libvirt-ubuntu-1604.zip
similarity index 100%
rename from buildenv-libvirt-ubuntu-16.zip
rename to buildenv-libvirt-ubuntu-1604.zip
diff --git a/buildenv-libvirt-ubuntu-18.zip b/buildenv-libvirt-ubuntu-1804.zip
similarity index 100%
rename from buildenv-libvirt-ubuntu-18.zip
rename to buildenv-libvirt-ubuntu-1804.zip
--
2.23.0
5 years
[libvirt] [PATCH] spec: fix indentation fix
by Ján Tomko
The RPM tags must not be indented.
Fixes: 6b8ab20f9b9b1a9383bd2cb9a075f57beb196c1c
Signed-off-by: Ján Tomko <jtomko(a)redhat.com>
---
libvirt.spec.in | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
Pushed as a build breaker fix.
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 4d75fbecaf..bd08222527 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -336,11 +336,11 @@ BuildRequires: device-mapper-devel
BuildRequires: xfsprogs-devel
%if %{with_storage_rbd}
%if 0%{?fedora} || 0%{?rhel} > 7
- BuildRequires: librados-devel
- BuildRequires: librbd-devel
+BuildRequires: librados-devel
+BuildRequires: librbd-devel
%else
- BuildRequires: librados2-devel
- BuildRequires: librbd1-devel
+BuildRequires: librados2-devel
+BuildRequires: librbd1-devel
%endif
%endif
%if %{with_storage_gluster}
--
2.21.0
5 years
[libvirt] [PATCH] spec: fix indentation
by Ján Tomko
The recent specfile addition broke syntax-check:
cppi: ../libvirt.spec.in: line 338: not properly indented
cppi: ../libvirt.spec.in: line 341: not properly indented
cppi: ../libvirt.spec.in: line 344: not properly indented
Fixes: ac063cb2e76d64a907f96bf0b6a29da4eb484ebc
Signed-off-by: Ján Tomko <jtomko(a)redhat.com>
---
Push under the 'are we still doing syntax-check?' rule
libvirt.spec.in | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 01f28e62d6..4d75fbecaf 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -335,13 +335,13 @@ BuildRequires: device-mapper-devel
# For XFS reflink clone support
BuildRequires: xfsprogs-devel
%if %{with_storage_rbd}
-%if 0%{?fedora} || 0%{?rhel} > 7
-BuildRequires: librados-devel
-BuildRequires: librbd-devel
-%else
-BuildRequires: librados2-devel
-BuildRequires: librbd1-devel
-%endif
+ %if 0%{?fedora} || 0%{?rhel} > 7
+ BuildRequires: librados-devel
+ BuildRequires: librbd-devel
+ %else
+ BuildRequires: librados2-devel
+ BuildRequires: librbd1-devel
+ %endif
%endif
%if %{with_storage_gluster}
BuildRequires: glusterfs-api-devel >= 3.4.1
--
2.19.2
5 years
[libvirt] [jenkins-ci PATCH 0/1] jenkins: Start building on Ubuntu
by Andrea Bolognani
This patch is intended to start a slightly larger discussion about
our plans for the CentOS CI environment going forward.
At the moment, we have active builders for
CentOS 7
Debian 9
Debian 10
Fedora 30
Fedora 31
Fedora Rawhide
FreeBSD 11
FreeBSD 12
but we don't have builder for
Debian sid
FreeBSD -CURRENT
Ubuntu 16.04
Ubuntu 18.04
despite them being fully supported in the libvirt-jenkins-ci
repository.
This makes sense for sid and -CURRENT, since the former covers the
same "freshest Linux packages" angle that Rawhide already takes care
of and the latter is often broken and not trivial to keep updated;
both Ubuntu targets, however, should IMHO be part of the CentOS CI
environment. Hence this series :)
Moreover, we're in the process of adding
CentOS 8
openSUSE Leap 15.1
openSUSE Tumbleweed
as targets, of which the first two should also IMHO be added as they
would provide useful additional coverage.
The only reason why I'm even questioning whether this should be done
is capacity for the hypervisor host: the machine we're running all
builders on has
CPUs: 8
Memory: 32 GiB
Storage: 450 GiB
and each of the guests is configured to use
CPUs: 2
Memory: 2 GiB
Storage: 20 GiB
So while we're good, and actually have plenty of room to grow, on
the memory and storage front, we're already overcommitting our CPUs
pretty significantly, which I guess is at least part of the reason
why builds take so long.
Can we afford to add 50% more load on the machine without making it
unusable? I don't know. But I think it would be worthwhile to at
least try and see how it handles an additional 25%, which is exactly
what this series does.
In my opinion, as long as the machine can keep up with demand and not
end up in a situation where it starts accumulating backlog jobs, it's
fine if builds take longer: developers who want to run a relatively
quick smoke test before posting patches can use Travis CI or 'make
ci-check@...' locally for the purpose, whereas the role of CentOS CI
in my eyes is to try and catch as many issues as possible after merge
so that they don't end up in a release. But I realize others might
see it differently, hence this lenghty cover letter :)
Andrea Bolognani (1):
jenkins: Start building on Ubuntu
jenkins/jobs/defaults.yaml | 2 ++
jenkins/projects/libvirt-dbus.yaml | 1 +
jenkins/projects/libvirt-sandbox.yaml | 2 ++
jenkins/projects/libvirt-tck.yaml | 2 ++
jenkins/projects/libvirt.yaml | 2 ++
jenkins/projects/virt-manager.yaml | 2 ++
6 files changed, 11 insertions(+)
--
2.23.0
5 years
[libvirt] [jenkins-ci PATCH v2 0/8] Add CentOS 8 to libvirt-jenkins-ci
by Fabiano Fidêncio
In order to add CentOS 8 to jenkins-ci, we had to:
- Adjust lcitool to generate unattended scripts based on templates
instead of using the templates themselves, as a new parameter is
expected on kickstart files for RHEL / CentOS 8 (or newer);
- Enable the EPEL and PowerTools repos;
Then, the following projects have been added:
- libvirt
- Some adjustments had to be done as some dependencies got removed from
CentOS 8;
- libvirt-glib
- libvirt-dbus
- Some adjustments had to be done as flake8 doesn't pull all the needed
dependencies when installed on CentOS 8;
- libvirt-go
- libvirt-go-xml
- libvirt-ocaml
- libvirt-perl
- libvirt-python
- virt-viewer
- Some adjustments had to be done as libgovirt-devel and gtk-vnc2-devel
are not present anymore on CentOS 8;
- osinfo-db-tools
- oisnfo-db
- libosinfo
- virt-manager
The projects which were not added due to missing dependencies are:
- libvirt-cim
- libvirt-sandbox
- libvirt-tck
Fabiano Fidêncio (8):
lcitool: Generate the unattended script file
lcitool: Use install_url in the unattended install files
guests: Add CentOS 8
mappings: Adjustments for CentOS 8
guests: Install EPEL repo on all CentOS guests
guests: Enable PowerTools repo on CentOS 8 guests
guests: Add projects to CentOS 8
guests: Build projects on CentOS 8
guests/configs/kickstart.cfg | 6 +++++
guests/host_vars/libvirt-centos-8/docker.yml | 2 ++
guests/host_vars/libvirt-centos-8/install.yml | 2 ++
guests/host_vars/libvirt-centos-8/main.yml | 22 ++++++++++++++++
guests/inventory | 1 +
guests/lcitool | 26 ++++++++++++++++++-
guests/playbooks/build/jobs/defaults.yml | 2 ++
guests/playbooks/build/projects/libosinfo.yml | 1 +
.../playbooks/build/projects/libvirt-dbus.yml | 2 ++
guests/playbooks/build/projects/libvirt.yml | 1 +
.../build/projects/osinfo-db-tools.yml | 1 +
.../playbooks/build/projects/virt-manager.yml | 3 +++
guests/playbooks/update/tasks/base.yml | 9 ++++++-
guests/vars/mappings.yml | 4 +++
jenkins/jobs/defaults.yaml | 2 ++
jenkins/projects/libosinfo.yaml | 1 +
jenkins/projects/libvirt-dbus.yaml | 2 ++
jenkins/projects/libvirt.yaml | 1 +
jenkins/projects/osinfo-db-tools.yaml | 1 +
jenkins/projects/virt-manager.yaml | 3 +++
20 files changed, 90 insertions(+), 2 deletions(-)
create mode 100644 guests/host_vars/libvirt-centos-8/docker.yml
create mode 100644 guests/host_vars/libvirt-centos-8/install.yml
create mode 100644 guests/host_vars/libvirt-centos-8/main.yml
--
2.23.0
5 years
[libvirt] [PATCH] docs: prefer to use rst2html5 instead of rst2html
by Daniel P. Berrangé
Our website is written assuming HTML5 standard & doctype:
commit b1c81567c7172bc9dcd701cf46ea3f87725d62c7
Author: Daniel P. Berrangé <berrange(a)redhat.com>
Date: Wed Jul 26 18:01:25 2017 +0100
docs: switch to using HTML5 doctype declaration
so we want the RST conversion to also use HTML5. Ubuntu 16.04 still
only has the HTML4 generating tools though, so we have that as a
fallback.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
m4/virt-external-programs.m4 | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/m4/virt-external-programs.m4 b/m4/virt-external-programs.m4
index ed634a4c73..aad21c81bf 100644
--- a/m4/virt-external-programs.m4
+++ b/m4/virt-external-programs.m4
@@ -33,10 +33,13 @@ AC_DEFUN([LIBVIRT_CHECK_EXTERNAL_PROGRAMS], [
then
AC_MSG_ERROR("xsltproc is required to build libvirt")
fi
- AC_PATH_PROGS([RST2HTML], [rst2html rst2html.py rst2html-3], [])
+
+ dnl Drop the rst2html (aka HTML4) variants once we
+ dnl stop supporting Ubuntu 16.04 (Xenial)
+ AC_PATH_PROGS([RST2HTML], [rst2html5 rst2html5.py rst2html5-3 rst2html rst2html.py rst2html-3], [])
if test -z "$RST2HTML"
then
- AC_MSG_ERROR("rst2html is required to build libvirt")
+ AC_MSG_ERROR("rst2html5/rst2html is required to build libvirt")
fi
AC_PATH_PROG([AUGPARSE], [augparse], [/usr/bin/augparse])
AC_PROG_MKDIR_P
--
2.23.0
5 years
[libvirt] [PATCH] scripts: ignore remote protocol checks if pdwtags crashes
by Daniel P. Berrangé
On Debian 10, pdwtags reliably segfaults when parsing the libvirt remote
protocol files. This crash was previously ignored by 'make check'
because of the way we piped the pdwtags output to the perl
post-processing scripts. When this was converted to use python it
mistakenly started being a fatal error. We need to explicitly ignore
pdwtags output if it exited with non-zero return code.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
scripts/check-remote-protocol.py | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/scripts/check-remote-protocol.py b/scripts/check-remote-protocol.py
index 201166fd9e..25caa19563 100644
--- a/scripts/check-remote-protocol.py
+++ b/scripts/check-remote-protocol.py
@@ -86,8 +86,12 @@ out, err = pdwtagsproc.communicate()
out = out.decode("utf-8")
err = err.decode("utf-8")
-if out == "" and err != "":
- print("WARNING: no output, pdwtags appears broken:", file=sys.stderr)
+if out == "" or pdwtagsproc.returncode != 0:
+ if out == "":
+ print("WARNING: no output, pdwtags appears broken:", file=sys.stderr)
+ else:
+ print("WARNING: exit code %d, pdwtags appears broken:" %
+ pdwtagsproc.returncode, file=sys.stderr)
for l in err.strip().split("\n"):
print("WARNING: %s" % l, file=sys.stderr)
print("WARNING: skipping the remote protocol test", file=sys.stderr)
--
2.23.0
5 years
[libvirt] [PATCH] docs: switch to use rst2html5 instead of rst2html
by Daniel P. Berrangé
Now that we don't have to support CentOS 7's python2-docutils, we can
use the rst2html5 tool instead, which generates HTML5 output instead
of HTML4 output. This matches what we used for the original HTML docs
since
commit b1c81567c7172bc9dcd701cf46ea3f87725d62c7
Author: Daniel P. Berrangé <berrange(a)redhat.com>
Date: Wed Jul 26 18:01:25 2017 +0100
docs: switch to using HTML5 doctype declaration
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
m4/virt-external-programs.m4 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/m4/virt-external-programs.m4 b/m4/virt-external-programs.m4
index ed634a4c73..a23c69d54b 100644
--- a/m4/virt-external-programs.m4
+++ b/m4/virt-external-programs.m4
@@ -33,7 +33,7 @@ AC_DEFUN([LIBVIRT_CHECK_EXTERNAL_PROGRAMS], [
then
AC_MSG_ERROR("xsltproc is required to build libvirt")
fi
- AC_PATH_PROGS([RST2HTML], [rst2html rst2html.py rst2html-3], [])
+ AC_PATH_PROGS([RST2HTML], [rst2html5 rst2html5.py rst2html5-3], [])
if test -z "$RST2HTML"
then
AC_MSG_ERROR("rst2html is required to build libvirt")
--
2.23.0
5 years