After commit 3e2f27e1, I've noticed build failures of virt-login-shell
when libapparmor-devel is installed on the build host

CCLD     virt-login-shell
../src/.libs/libvirt-setuid-rpc-client.a(libvirt_setuid_rpc_client_la-vircommand.o):
In function `virExec':
/home/jfehlig/virt/upstream/libvirt/src/util/vircommand.c:653: undefined
reference to `aa_change_profile'
collect2: error: ld returned 1 exit status

I was about to commit an easy fix under the build-breaker rule
(build-fix-1.patch), but thought to extend the notion of SECDRIVER_LIBS
to SECDRIVER_CFLAGS, and use both throughout src/Makefile.am where it
makes sense (build-fix-2.patch).

Should I just stick with the simple fix, or is something along the lines
of patch 2 preferred?

Regards,
Jim

>From a0f35945f3127ab70d051101037e821b1759b4bb Mon Sep 17 00:00:00 2001
From: Jim Fehlig <jfehlig@suse.com>
Date: Mon, 21 Oct 2013 15:30:02 -0600
Subject: [PATCH] build: fix virt-login-shell build with apparmor

With libapparmor-devel installed, virt-login-shell fails to link

CCLD     virt-login-shell
../src/.libs/libvirt-setuid-rpc-client.a(libvirt_setuid_rpc_client_la-vircommand.o): In function `virExec':
/home/jfehlig/virt/upstream/libvirt/src/util/vircommand.c:653: undefined reference to `aa_change_profile'
collect2: error: ld returned 1 exit status

Fix by linking libvirt_setuid_rpc_client with previously determined
SECDRIVER_LIBS in src/Makefile.am.  While at it, introduce SECDRIVER_CFLAGS
and use both throughout src/Makefile.am where it makes sense.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Currently, if access(path, mode) is invoked, we check if @path has this
special prefix SYSFS_PREFIX. If it does, we modify the path a bit and
call realaccess. If it doesn't we act just like a wrapper and call
realaccess directly. However, we are mocking fopen() as well. And as one
can clearly see there, fopen("/proc/cgroups") will succeed. Hence, we
have an error in our mocked access(): We need to check whether @path is
not equal to /proc/cgroups as it may not exists on real system we're
running however we definitely know how to fopen() it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

As stated in the comment above introduction of the lv_abs_top_builddir
variable, older automake doesn't provide abs_top_builddir variable.
Hence, we are creating our own one with lv_ prefix. However, when
exporting env variables to the tests, the variables are not evaluated
but only substituted. Hence:

  LIBVIRT_DRIVER_DIR="$(abs_top_builddir)/src/.libs"

is set to "/src/.libs" with old automake (even though we *think* we've
set the $abs_top_builddir variable just a few line above).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In commit b46c4787 I changed the code to
watch long running jobs in virsh. Unfortunately I didn't take into
account that poll may get a hangup if the terminal is not a TTY and will
be closed.

This patch avoids polling the STDIN fd when there's no TTY.

s/informations/information
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>

HW_PHYSMEM is available on Mac OS X as well as FreeBSD, however,
its resulting value for Mac OS X is 32 bits. Mac OS X provides
HW_MEMSIZE that is 64 bits version of HW_PHYSMEM. We have to use it.

I tested the patch on Mac OS X 10.6.8, 10.7.4, 10.8.5 and FreeBSD 9.2.
Signed-off-by: NRyota Ozaki <ozaki.ryota@gmail.com>

This patch (and the two patches that precede it) resolve:

  https://bugzilla.redhat.com/show_bug.cgi?id=1005682

When libvirt was changed to delay the final cleanup of device removal
until the qemu process had signaled it with a DEVICE_DELETED event for
that device, the hostdev removal function
(qemuDomainRemoveHostDevice()) was written to properly handle the
removal of a hostdev that was actually an SRIOV virtual function
(defined with <interface type='hostdev'>). However, the function used
to search for a device matching the alias name provided in the
DEVICE_DELETED message (virDomainDefFindDevice()) would search through
the list of netdevs before hostdevs, so qemuDomainRemoveHostDevice()
was never called; instead the netdev function,
qemuDomainRemoveNetDevice() (which *doesn't* properly cleanup after
removal of <interface type='hostdev'>), was called.

(As a reminder - each <interface type='hostdev'> results in a
virDomainNetDef which contains a virDomainHostdevDef having a parent
type of VIR_DOMAIN_DEVICE_NET, and parent.data.net pointing back to
the virDomainNetDef; both Defs point to the same device info object
(and the info contains the device's "alias", which is used by qemu to
identify the device). The virDomainHostdevDef is added to the domain's
hostdevs list *and* the virDomainNetDef is added to the domain's nets
list, so searching either list for a particular alias will yield a
positive result.)

This function modifies the qemuDomainRemoveNetDevice() to short
circuit itself and call qemu DomainRemoveHostDevice() instead when the
actual device is a VIR_DOMAIN_NET_TYPE_HOSTDEV (similar logic to what
is done in the higher level qemuDomainDetachNetDevice())

Note that even if virDomainDefFindDevice() changes in the future so
that it finds the hostdev entry first, the current code will continue
to work properly.

pure code movement to setup for next patch.

This function was called in three places, and in each the call was
qualified by a slightly different conditional. In reality, this
function should only be called for a hostdev if all of the following
are true:

  1) mode='subsystem'
  2) type='pci'
  3) there is a parent device definition which is an <interface>
     (VIR_DOMAIN_DEVICE_NET)

We can simplify the callers and make them more consistent by checking
these conditions at the top ov qemuDomainHostdevNetConfigRestore and
returning 0 if one of them isn't satisfied.

The location of the call to qemuDomainHostdevNetConfigRestore() has
also been changed in the hot-plug case - it is moved into the caller
of its previous location (i.e. from qemuDomainRemovePCIHostDevice() to
qemuDomainRemoveHostDevice()). This was done to be more consistent
about which functions pay attention to whether or not this is one of
the special <interface> hostdevs or just a normal hostdev -
qemuDomainRemoveHostDevice() already contained a call to
networkReleaseActualDevice() and virDomainNetDefFree(), so it makes
sense for it to also handle the resetting of the device's MAC address
and vlan tag (which is what's done by
qemuDomainHostdevNetConfigRestore()).

Many people will not want the setuid virt-login-shell binary
installed by default, so move it into a separate sub-RPM
named libvirt-login-shell. This RPM is only generated if
LXC is enabled
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Avoid people introducing security flaws in their apps by
forbidding the use of libvirt.so in setuid programs, with
a check in virInitialize.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Most of the usage of getuid()/getgid() is in cases where we are
considering what privileges we have. As such the code should be
using the effective IDs, not real IDs.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

We already have stubs for getuid, geteuid, getgid but
not for getegid. Something in gnulib already does a
check for it during configure, so we already have the
HAVE_GETEGID macro defined.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

We don't want setuid programs automatically spawning libvirtd,
so disable any use of autostart when setuid.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

We don't know enough about quality of external libraries used
for non-UNIX transports, nor do we want to spawn external
commands when setuid. Restrict to the bare minimum which is
UNIX transport for local usage. Users shouldn't need to be
running setuid if connecting to remote hypervisors in any
case.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The use of getenv is typically insecure, and we want people
to use our wrappers, to force them to think about setuid
needs.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Unconditional use of getenv is not secure in setuid env.
While not all libvirt code runs in a setuid env (since
much of it only exists inside libvirtd) this is not always
clear to developers. So make all the code paranoid, even
if it only ever runs inside libvirtd.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When running setuid, we must be careful about what env vars
we allow commands to inherit from us. Replace the
virCommandAddEnvPass function with two new ones which do
filtering

  virCommandAddEnvPassAllowSUID
  virCommandAddEnvPassBlockSUID

And make virCommandAddEnvPassCommon use the appropriate
ones
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The virt-login-shell binary shouldn't need to execute programs
relying on $PATH, but just in case set a fixed $PATH value
of /bin:/usr/bin
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The libvirt.so library has far too many library deps to allow
linking against it from setuid programs. Those libraries can
do stuff in __attribute__((constructor) functions which is
not setuid safe.

The virt-login-shell needs to link directly against individual
files that it uses, with all library deps turned off except
for libxml2 and libselinux.

Create a libvirt-setuid-rpc-client.la library which is linked
to by virt-login-shell. A config-post.h file allows this library
to disable all external deps except libselinux and libxml2.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

We don't want to inherit any FDs in the new namespace
except for the stdio FDs. Explicitly close them all,
just in case some do not have the close-on-exec flag
set.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

We must not allow file/syslog/journald log outputs when running
setuid since they can be abused to do bad things. In particular
the 'file' output can be used to overwrite files.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Care must be taken accessing env variables when running
setuid. Introduce a virGetEnvAllowSUID for env vars which
are safe to use in a setuid environment, and another
virGetEnvBlockSUID for vars which are not safe. Also add
a virIsSUID helper method for any other non-env var code
to use.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The virConnectDomainXMLToNative API should require 'connect:write'
not 'connect:read', since it will trigger execution of the QEMU
binaries listed in the XML.

Also make virConnectDomainXMLFromNative API require a full
read-write connection and 'connect:write' permission. Although the
current impl doesn't trigger execution of QEMU, we should not
rely on that impl detail from an API permissioning POV.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

s/effect/affect
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>

The meaning of one line of code was accidentally inverted.
Signed-off-by: NEric Blake <eblake@redhat.com>

Commit e3ef20d7 allows user to configure migration ports range via
qemu.conf. However, it forgot to update augeas definition file and
even the test data was malicious.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

host-model is a nice idea but it's current implementation make it
useless on some hosts so it should be used with care.

https://bugzilla.redhat.com/show_bug.cgi?id=1019053

https://bugzilla.redhat.com/show_bug.cgi?id=1019053

When we migrate vms concurrently, there's a chance that libvirtd on
destination assigns the same port for different migrations, which will
lead to migration failure during prepare phase on destination. So we use
virPortAllocator here to solve the problem.
Signed-off-by: NWang Yufei <james.wangyufei@huawei.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

In fact, the suffix should be _QUIET not _QUIT to stress the
fact, that no OOM error is reported on error.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

netcfStateInitialize() initializes the driverState variable,
and when netcfStateCleanup is called, it will call virReportError()
if driverState is NULL.
This is not consistent with what other state objects are doing,
they return -1 without reporting an error in such cases.

See also
https://www.redhat.com/archives/libvir-list/2013-October/msg00809.html:

On Thu, Oct 17, 2013 at 01:40:19PM +0100, Daniel P. Berrange wrote:
> We don't want virStateCleanup to skip execution if virStateInitialize
> has failed though - every callback in virStateCleanup should be written
> to be safe if its corresponding init function hasn't run.

Introduced by 7b87a3
When I quit the process which only register VIR_DOMAIN_EVENT_ID_REBOOT,
I got error like:
"libvirt: XML-RPC error : internal error: domain event 0 not registered".
Then I add the following code, it fixed.
Signed-off-by: NZhou Yimin <zhouyimin@huawei.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

If we fail to get domain, we had to judge whether
it's null or not when doing 'cleanup'.
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>

The header definition didn't match the function declaration, so adjusted
header to reflect the definition.

Found during a Coverity build where STATIC_ANALYSIS is enabled resulting
in the internal.h adding __nonnull__ handling to arguments.

Commit '6d264c91' added support for the qemuMonitorJSONDrivePivot() and
commit 'fbc3adc9' added a corresponding test which ended up triggering
the build failure which I didn't notice until today!

'--print-xml' option is very useful for doing some test.
But we had to specify a real domain for it.
This patch could enable us to specify a fake domain
when using --print-xml option.
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

Code cleanup: remove explicit NULL comparisons like ptr == NULL and
ptr != NULL from the ESX code, replacing them with the simpler ptr
and !ptr.

Part three of three.

Code cleanup: remove explicit NULL comparisons like ptr == NULL and
ptr != NULL from the ESX code, replacing them with the simpler ptr
and !ptr.

Part two of three.

Code cleanup: remove explicit NULL comparisons like ptr == NULL and
ptr != NULL from the ESX code, replacing them with the simpler ptr
and !ptr.

Part one of three.

QEMU has support for SASL auth for SPICE guests, but libvirt
has no way to enable it. Following the example from VNC where
it is globally enabled via qemu.conf
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>