Since 76b644c3 when the support for RAM filesystems was introduced,
libvirt accepted the following XML:
<source usage='1024' unit='KiB'/>

This was parsed correctly and internally stored in bytes, but it
was formatted as (with an extra 's'):
<source usage='1024' units='KiB'/>
When read again, this was treated as if the units were missing,
meaning libvirt was unable to parse its own XML correctly.

The usage attribute was documented as being in KiB, but it was not
scaled if the unit was missing. Transient domains still worked,
because this was balanced by an extra 'k' in the mount options.

This patch:
Changes the parser to use 'units' instead of 'unit', as the latter
was never documented (fixing persistent domains) and some programs
(libvirt-glib, libvirt-sandbox) already parse the 'units' attribute.

Removes the extra 'k' from the tmpfs mount options, which is needed
because now we parse our own XML correctly.

Changes the default input unit to KiB to match documentation, fixing:
https://bugzilla.redhat.com/show_bug.cgi?id=1015689
(cherry picked from commit 3f029fb5)

After successful @cmd construction the memory where @keys points to is
part of @cmd. Avoid double freeing it.
(cherry picked from commit 3e8343e1)

After freeing the bitmap pointer, it must set the pointer to NULL.
This will avoid any other use of the freed memory of the bitmap pointer.

https://bugzilla.redhat.com/show_bug.cgi?id=1006710Signed-off-by: NLiuji (Jeremy) <jeremy.liu@huawei.com>
(cherry picked from commit ef5d51d4)

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

1,003 bytes in 1 blocks are definitely lost in loss record 599 of 635
==404== by 0x50728A7: virBufferAddChar (virbuffer.c:185)
==404== by 0x50BC466: virSystemdEscapeName (virsystemd.c:67)
==404== by 0x50BC6B2: virSystemdMakeSliceName (virsystemd.c:108)
==404== by 0x50BC870: virSystemdCreateMachine (virsystemd.c:169)
==404== by 0x5078267: virCgroupNewMachine (vircgroup.c:1498)
(cherry picked from commit 09b48562)

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

Commit 38ab1225 changed the default value of ret from true to false but
forgot to set ret = true when job is NONE. Thus, virsh domjobinfo
returned 1 when there was no job running for a domain but it used to
(and should) return 0 in this case.
(cherry picked from commit f084caae)

Commit 27e81517 set the payload size to 256 KB, which is
actually the max packet size, including the size of the header.

Reduce this by VIR_NET_MESSAGE_HEADER_MAX (24) and set
VIR_NET_MESSAGE_LEGACY_PAYLOAD_MAX to 262120, which was the original
value before increasing the limit in commit eb635de1.

(cherry picked from commit 609eb987)

The libvirtd server pushes data out to clients. It does not
know what protocol version the client might have, so must be
conservative and use the old payload limits. ie send no more
than 256kb of data per packet.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 27e81517)

When a client disconnects from libvirtd, all event callbacks
must be removed. This involves running the public API

  virConnectDomainEventDeregisterAny

This code does not run in normal API dispatch context, so no
identity was set. The result was that the access control drivers
denied the attempt to deregister callbacks. The callbacks thus
continued to trigger after the client was free'd causing fairly
predictable use of free memory & a crash.

This can be triggered by any client with readonly access when
the ACL drivers are active.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 8294aa0c)

Since the wait is done during migration (still inside
QEMU_ASYNC_JOB_MIGRATION_OUT), the code should enter the monitor as such
in order to prohibit all other jobs from interfering in the meantime.
This patch fixes bug #1009886 in which qemuDomainGetBlockInfo was
waiting on the monitor condition and after GetSpiceMigrationStatus
mangled its internal data, the daemon crashed.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1009886
(cherry picked from commit 484cc321)

The fix for CVE-2013-4311 had a pre-requisite enhancement
to the identity code

  commit db7a5688
  Author: Daniel P. Berrange <berrange@redhat.com>
  Date:   Thu Aug 22 16:00:01 2013 +0100

    Also store user & group ID values in virIdentity

This had a typo which caused the group ID to overwrite the
user ID string. This meant any checks using this would have
the wrong ID value. This only affected the ACL code, not the
initial polkit auth. It also leaked memory.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit e4697b92)

After commit 8aecd351 it'll detect
that a required option is not defined and it will assert and exit with:

virsh.c:1364: vshCommandOpt: Assertion `valid->name' failed.

Problem has been latent since commit ed23b106.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit fe64499d)

The 'stats' variable was not initialized to NULL, so if some
early validation of the RPC call fails, it is possible to jump
to the 'cleanup' label and VIR_FREE an uninitialized pointer.
This is a security flaw, since the API can be called from a
readonly connection which can trigger the validation checks.

This was introduced in release v0.9.1 onwards by

  commit 158ba873
  Author: Daniel P. Berrange <berrange@redhat.com>
  Date:   Wed Apr 13 16:21:35 2011 +0100

    Merge all returns paths from dispatcher into single path
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit e7f400a1)

With the existing pkcheck (pid, start time) tuple for identifying
the process, there is a race condition, where a process can make
a libvirt RPC call and in another thread exec a setuid application,
causing it to change to effective UID 0. This in turn causes polkit
to do its permission check based on the wrong UID.

To address this, libvirt must get the UID the caller had at time
of connect() (from SO_PEERCRED) and pass a (pid, start time, uid)
triple to the pkcheck program.

This fix requires that libvirt is re-built against a version of
polkit that has the fix for its CVE-2013-4288, so that libvirt
can see 'pkg-config --variable pkcheck_supports_uid polkit-gobject-1'
Signed-off-by: NColin Walters <walters@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 922b7fda)

The polkit access driver will want to use the process start
time field. This was already set for network identities, but
not for the system identity.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit e65667c0)

Future improvements to the polkit code will require access to
the numeric user ID, not merely user name.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit db7a5688)

Bother those kernel developers.  In the latest rawhide, kernel
and glibc have now been unified so that <netinet/in.h> and
<linux/in6.h> no longer clash; but <linux/if_bridge.h> is still
not self-contained.  Because of the latest header change, the
build is failing with:

checking for linux/param.h... no
configure: error: You must install kernel-headers in order to compile libvirt with QEMU or LXC support

with details:

In file included from conftest.c:561:0:
/usr/include/linux/in6.h:71:18: error: field 'flr_dst' has incomplete type
  struct in6_addr flr_dst;

We need a workaround to avoid our workaround :)

* configure.ac (NETINET_LINUX_WORKAROUND): New test.
* src/util/virnetdevbridge.c (includes): Use it.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit e62e0094)

This gives us a RO got, otherwise Debian's lintian complains:

W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so
W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_storage.so
W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_uml.so
W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_vbox.so
W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_xen.so
W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_nwfilter.so
W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_storage.so
W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_uml.so
W: libvirt-sanlock: hardening-no-relro usr/lib/libvirt/lock-driver/sanlock.so
(cherry picked from commit f1f0e53b)

(cherry picked from commit fe502de3)

The @qemunbd variable can be used uninitialized.

(cherry picked from commit 2dba0323)

* configure.ac docs/news.html.in libvirt.spec.in: update for the release
* po/*.po*: merged new localizations and regenerated

Remove unused 'cgroup' variable in qemuDomainAttachDeviceDiskLive() to
resolve coverity DEADCODE complaint

When virBufferError is ok in cmdAttachDisk, the latter
should 'goto cleanup', instead of returning a false to
prevent memory leaking.
Signed-off-by: NEric Blake <eblake@redhat.com>

Since virtlockd is only built when libvirtd is built, we should
not install its auxiliary files unconditionally.  This solves
two failures.  1. 'make distcheck' complains:

rm -f Makefile
ERROR: files left in build directory after distclean:
./src/virtlockd.8

2. './autobuild.sh' complains:

Checking for unpackaged file(s): /usr/lib/rpm/check-files
/home/eblake/rpmbuild/BUILDROOT/mingw-libvirt-1.1.1-1.fc19.eblake1377879911.x86_64
error: Installed (but unpackaged) file(s) found:
   /usr/i686-w64-mingw32/sys-root/mingw/etc/libvirt/virtlockd.conf

/usr/i686-w64-mingw32/sys-root/mingw/share/augeas/lenses/tests/test_virtlockd.aug
   /usr/i686-w64-mingw32/sys-root/mingw/share/augeas/lenses/virtlockd.aug
   /usr/i686-w64-mingw32/sys-root/mingw/share/man/man8/virtlockd.8
   /usr/x86_64-w64-mingw32/sys-root/mingw/etc/libvirt/virtlockd.conf

/usr/x86_64-w64-mingw32/sys-root/mingw/share/augeas/lenses/tests/test_virtlockd.aug
   /usr/x86_64-w64-mingw32/sys-root/mingw/share/augeas/lenses/virtlockd.aug
   /usr/x86_64-w64-mingw32/sys-root/mingw/share/man/man8/virtlockd.8

* src/Makefile.am (CLEANFILES): Add virtlockd.8.
(man8_MANS, conf_DATA, augeas_DATA, augeastest_DATA): Only install
virtlockd files when daemon is built.
Signed-off-by: NEric Blake <eblake@redhat.com>

'make distcheck' was failing with:
make[3]: Entering directory `/home/eblake/libvirt-tmp2/libvirt-1.1.1/_build/docs'
perl ../../docs/genaclperms.pl ../../src/access/viraccessperm.h > ../../docs/aclperms.htmlinc
/bin/sh: ../../docs/aclperms.htmlinc: Permission denied

when simulating the case of a user doing a VPATH build from a
read-only source tree.  The culprit?  BUILT_SOURCES are _always_
built, and so must NOT be built into srcdir and need not be part
of the tarball.  On the other hand, shipped files must never
depend on files in the builddir.  While it would be possible to
fix the problem by generating aclperms.htmlinc into builddir,
we then have the problem that we ship acl.html - we'd have to
rejigger a lot of things to not ship pre-built html.  So this
patch goes the other direction - we don't need BUILT_SOURCES,
but instead ensure that we have proper dependencies so that
all files in srcdir are up-to-date at the time the tarball is
created.  And because we ship html files in the tarball, that
implies we don't expect users to be able to rebuild them, so
we must not clean any files that would trigger a rebuild except
under the maintainer rules.

* docs/Makefile.am (BUILT_SOURCES): Delete.
(CLEANFILES): Downgrade aclperms.htmlinc cleanup...
(maintainer-clean-local): ...and move hvsupport.html.in...
(MAINTAINERCLEANFILES): ...to a maintainer action.
(hvsupport.html.in): Write into srcdir.
(hvsupport.html): Ensure files are built in order.
(aclperms.htmlinc): Honor silent make.
(EXTRA_DIST): Ship aclperms.htmlinc.
Signed-off-by: NEric Blake <eblake@redhat.com>

With the 1.1.1 tarball, if a user does 'make && make distcheck',
things pass, but if they do 'make distcheck' after 'make clean',
there is an odd failure:

  GEN      ../../docs/devhelp/index.html
I/O error : Permission denied
I/O error : Permission denied
runtime error: file ../../docs/devhelp/devhelp.xsl line 43 element document
xsltDocumentElem: unable to save to ../../docs/devhelp/libvirt-virterror.html
I/O error : Permission denied
I/O error : Permission denied

This implies that the rules for 'make dist' are missing a
dependency - the generated documentation needs to be up-to-date
before creating the tarball, or else the tarball will be missing
files, where the end user will end up trying to rebuild files in
srcdir, and that fails when srcdir is read-only.

1.1.1 plus this patch now works without issues (other issues have
crept in to 1.1.2-rc1 that prevent 'make distcheck' from working,
but those will be cleaned up in later patches).

* docs/Makefile.am (dist-local): New dependency.
Signed-off-by: NEric Blake <eblake@redhat.com>

I noticed from an ./autobuild.sh run that we were installing a
virt-login-shell.exe binary when cross-building for mingw,
even though such a binary is necessarily worthless since the
code depends on lxc which is a Linux-only concept.

* tools/Makefile.am (conf_DATA, bin_PROGRAMS, dist_man1_MANS):
Make virt-login-shell installation conditional.
Signed-off-by: NEric Blake <eblake@redhat.com>

vhost only works in KVM mode at the moment, and is infact compiled
out if the emulator is built for non-native architecture. While it
may work at some point in the future for plain qemu, for now it's
just noise on the command line (and which contributes to arm cli
breakage).

Ubuntu libdbus.so links with -Bsymbolic-functions, which means
that we can only LD_PRELOAD functions that we directly call.
Functions which libdbus.so calls internally can not be replaced.
Thus we cannot use dbus_message_new_error or dbus_message_new_method_return
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

FreeBSD 10 recently changed their definition of RAND_MAX, to try
and cover the fact that their evenly distributed results of rand()
really are a smaller range than a full power of 2.  As a result,
I did some investigation, and learned:

1. POSIX requires random() to be evenly distributed across exactly
31 bits.  glibc also guarantees this for rand(), but the two are
unrelated, and POSIX only associates RAND_MAX with rand().
Avoiding RAND_MAX altogether thus avoids a build failure on
FreeBSD 10.

2. Concatenating random bits from a PRNG will NOT provide uniform
coverage over the larger value UNLESS the period of the original
PRNG is at least as large as the number of bits being concatenated.
Simple example: suppose that RAND_MAX were 1 with a period of 2**1
(which means that the PRNG merely alternates between 0 and 1).
Concatenating two successive rand() calls would then invariably
result in 01 or 10, which is a rather non-uniform distribution
(00 and 11 are impossible) and an even worse period (2**0, since
our second attempt will get the same number as our first attempt).
But a RAND_MAX of 1 with a period of 2**2 (alternating between
0, 1, 1, 0) provides sane coverage of all four values, if properly
tempered.  (Back-to-back calls would still only see half the values
if we don't do some tempering).  We therefore want to guarantee a
period of at least 2**64, preferably larger (as a tempering factor);
POSIX only makes this guarantee for random() with 256 bytes of info.

* src/util/virrandom.c (virRandomBits): Use constants that are
accurate for the PRNG we are using, not an unrelated PRNG.
(randomState): Ensure the period of our PRNG exceeds our usage.
Signed-off-by: NEric Blake <eblake@redhat.com>

Commit 29fe5d74 (released in 1.1.1) introduced a latent problem
for any caller of virSecurityManagerSetProcessLabel and where
the domain already had a uid:gid label to be parsed.  Such a
setup would collect the list of supplementary groups during
virSecurityManagerPreFork, but then ignores that information,
and thus fails to call setgroups() to adjust the supplementary
groups of the process.

Upstream does not use virSecurityManagerSetProcessLabel for
qemu (it uses virSecurityManagerSetChildProcessLabel instead),
so this problem remained latent until backporting the initial
commit into v0.10.2-maint (commit c061ff5e, released in 0.10.2.7),
where virSecurityManagerSetChildProcessLabel has not been
backported.  As a result of using a different code path in the
backport, attempts to start a qemu domain that runs as qemu:qemu
will end up with supplementary groups unchanged from the libvirtd
parent process, rather than the desired supplementary groups of
the qemu user.  This can lead to failure to start a domain
(typical Fedora setup assigns user 107 'qemu' to both group 107
'qemu' and group 36 'kvm', so a disk image that is only readable
under kvm group rights is locked out).  Worse, it is a security
hole (the qemu process will inherit supplemental group rights
from the parent libvirtd process, which means it has access
rights to files owned by group 0 even when such files should
not normally be visible to user qemu).

LXC does not use the DAC security driver, so it is not vulnerable
at this time.  Still, it is better to plug the latent hole on
the master branch first, before cherry-picking it to the only
vulnerable branch v0.10.2-maint.

* src/security/security_dac.c (virSecurityDACGetIds): Always populate
groups and ngroups, rather than only when no label is parsed.
Signed-off-by: NEric Blake <eblake@redhat.com>

The use of <> is a security issue for RPC parameters, since a
malicious client can set a huge array length causing arbitrary
memory allocation in the daemon.

It is also a robustness issue for RPC return values, because if
the stream is corrupted, it can cause the client to also allocate
arbitrary memory.

Use a syntax-check rule to prohibit any use of <>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The return values for the virConnectListAllSecrets call were not
bounds checked. This is a robustness issue for clients if
something where to cause corruption of the RPC stream data.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The return values for the virConnectListAllNWFilters call were not
bounds checked. This is a robustness issue for clients if
something where to cause corruption of the RPC stream data.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The return values for the virConnectListAllNodeDevices call were not
bounds checked. This is a robustness issue for clients if
something where to cause corruption of the RPC stream data.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The return values for the virConnectListAllInterfaces call were not
bounds checked. This is a robustness issue for clients if
something where to cause corruption of the RPC stream data.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The return values for the virConnectListAllNetworks call were not
bounds checked. This is a robustness issue for clients if
something where to cause corruption of the RPC stream data.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The return values for the virStoragePoolListAllVolumes call were not
bounds checked. This is a robustness issue for clients if
something where to cause corruption of the RPC stream data.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The return values for the virConnectListAllStoragePools call were not
bounds checked. This is a robustness issue for clients if
something where to cause corruption of the RPC stream data.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>