Since PIDs can be reused, polkit prefers to be given
a (PID,start time) pair. If given a PID on its own,
it will attempt to lookup the start time in /proc/pid/stat,
though this is subject to races.

It is safer if the client app resolves the PID start
time itself, because as long as the app has the client
socket open, the client PID won't be reused.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 979e9c56)

Conflicts:
	src/util/virprocess.c
	src/util/virstring.c
	src/util/virstring.h

The virBitmapParse function was calling virBitmapIsSet() function that
requires the caller to check the bounds of the bitmap without checking
them. This resulted into crashes when parsing a bitmap string that was
exceeding the bounds used as argument.

This patch refactors the function to use virBitmapSetBit without
checking if the bit is set (this function does the checks internally)
and then counts the bits in the bitmap afterwards (instead of keeping
track while parsing the string).

This patch also changes the "parse_error" label to a more common
"error".

The refactor should also get rid of the need to call sa_assert on the
returned variable as the callpath should allow coverity to infer the
possible return values.

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

Thanks to Alex Jia for tracking down the issue. This issue is introduced
by commit 0fc89098.

(cherry picked from commit 47b9127e)

Don't reuse the return value of virStorageBackendFileSystemIsMounted.
If it's 0, we'd return it even if the mount command failed.

Also, don't report another error if it's -1, since one has already
been reported.

Introduced by 258e06c8.

https://bugzilla.redhat.com/show_bug.cgi?id=981251
(cherry picked from commit 13fde7ce)

If qemuMonitorBlockJob returned 0, qemuDomainBlockPivot
might return 0 even if an error occured.

https://bugzilla.redhat.com/show_bug.cgi?id=977678
(cherry picked from commit c34107df)

When creating a virtual FC HBA with virsh/libvirt API, an error message
will be returned: "error: Node device not found",
also the 'nodedev-dumpxml' shows wrong information of wwpn & wwnn
for the new created device.

Signed-off-by: xschen@tnsoft.com.cn

This reverts f90af691 which switched wwpn & wwwn in the wrong place.

https://www.kernel.org/doc/Documentation/scsi/scsi_fc_transport.txt
(cherry picked from commit 3c0d5e22)

Conflicts:
	src/storage/storage_backend_scsi.c

If networkUnplugBandwidth is called on a network which has
no bandwidth defined, print a warning instead of crashing.

This can happen when destroying a domain with bandwidth if
bandwidth was removed from the network after the domain was
started.

https://bugzilla.redhat.com/show_bug.cgi?id=975359
(cherry picked from commit 658c932a)

Don't check for '\n' at the end of file if zero bytes were read.

Found by valgrind:
==404== Invalid read of size 1
==404==    at 0x529B09F: virCgroupGetValueStr (vircgroup.c:540)
==404==    by 0x529AF64: virCgroupMoveTask (vircgroup.c:1079)
==404==    by 0x1EB475: qemuSetupCgroupForEmulator (qemu_cgroup.c:1061)
==404==    by 0x1D9489: qemuProcessStart (qemu_process.c:3801)
==404==    by 0x18557E: qemuDomainObjStart (qemu_driver.c:5787)
==404==    by 0x190FA4: qemuDomainCreateWithFlags (qemu_driver.c:5839)

Introduced by 0d0b4098.

https://bugzilla.redhat.com/show_bug.cgi?id=978356
(cherry picked from commit 306c49ff)

Free the old XML strings before overwriting them if the user
has chosen to reedit the file or force the redefinition.

Found by Alex Jia trying to reproduce another bug:
https://bugzilla.redhat.com/show_bug.cgi?id=977430#c3
(cherry picked from commit 1e3a2529)

Cherry-picked from 38ada092

As a consequence of the cgroup layout changes from commit 'cfed9ad4', the
lxcDomainGetSchedulerParameters[Flags]()' and lxcGetSchedulerType() APIs
failed to return data for a non running domain.  This can be seen through
a 'virsh schedinfo <domain>' command which returns:

Scheduler      : Unknown
error: Requested operation is not valid: cgroup CPU controller is not mounted

Prior to that change a non running domain would return:

Scheduler      : posix
cpu_shares     : 0
vcpu_period    : 0
vcpu_quota     : 0
emulator_period: 0
emulator_quota : 0

This patch will restore the capability to return configuration only data
for a non running domain regardless of whether cgroups are available.

Conflicts:
	src/lxc/lxc_driver.c

  * Resolved conflict by using former lxcCgroupHasController() rather than
    virCgroupHasController()
  * Needed to add the code to fetch the 'vm'
     vm = virDomainObjListFindByUUID(driver->domains, domain->uuid);
     if (vm == NULL) {
         virReportError(VIR_ERR_INTERNAL_ERROR,
                        _("No such domain %s"), domain->uuid);
         goto cleanup;
     }
  * Used 'ret = strdup("posix");' rather than VIR_STRDUP(ret, "posix");
    and added the virReportOOMError(); on failure.

Cherry-picked from b2375453

As a consequence of the cgroup layout changes from commit '632f78ca', the
qemuDomainGetSchedulerParameters[Flags]()' and qemuGetSchedulerType() APIs
failed to return data for a non running domain.  This can be seen through
a 'virsh schedinfo <domain>' command which returns:

Scheduler      : Unknown
error: Requested operation is not valid: cgroup CPU controller is not mounted

Prior to that change a non running domain would return:

Scheduler      : posix
cpu_shares     : 0
vcpu_period    : 0
vcpu_quota     : 0
emulator_period: 0
emulator_quota : 0

This patch will restore the capability to return configuration only data
for a non running domain regardless of whether cgroups are available.

Conflicts:
	src/qemu/qemu_driver.c

 * Resolved conflict by using former qemuCgroupHasController() rather than
   virCgroupHasController()
 * Needed to add the code to fetch the 'vm'
      vm = virDomainObjListFindByUUID(driver->domains, dom->uuid);
      if (vm == NULL) {
          virReportError(VIR_ERR_INTERNAL_ERROR,
                         _("No such domain %s"), dom->uuid);
          goto cleanup;
      }
* Used 'ret = strdup("posix");' rather than VIR_STRDUP(ret, "posix");
  and added the virReportOOMError(); on failure.

Don't free the stream on error if we've successfully added it
to the hash table, since it will be freed by virChrdevHashEntryFree
callback.

Preserve the error message before calling virStreamFree, since it
resets the error.

Introduced by 47161382, crashing since 69218922.

Reported by Sergey Fionov on libvir-list.
(cherry picked from commit a32b4174)

Change the socket path to match the one used by lockd driver.

https://bugzilla.redhat.com/show_bug.cgi?id=968128
(cherry picked from commit 70fe1295)

Use the host number as the host number when constructing the sysfs path
instead of the variable we are trying to fill.

https://bugzilla.redhat.com/show_bug.cgi?id=973543
(cherry picked from commit 371c1551)

This should resolve:

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

The problem was that qemuUpdateActivePciHostdevs was returning 0
(success) when no hostdevs were present, but would otherwise return -1
(failure) even when it completed successfully. It is only called from
qemuProcessReconnect(), and when qemuProcessReconnect got back an
error, it would not only stop reconnecting, but would terminate the
guest qemu process "to remove danger of it ending up running twice if
user tries to start it again later".

(This bug was introduced in commit 011cf7ad, which was pushed between
v1.0.2 and v1.0.3, so all maintenance branches from v1.0.3 up to 1.0.5
will need this one line patch applied.)
(cherry picked from commit 2ea45647)

CVE-2013-1962

remoteDispatchStoragePoolListAllVolumes wasn't freeing the pool.
The pool also held a reference to the connection, preventing it from
getting freed and closing the netcf interface driver, which held two
sockets open.
(cherry picked from commit ca697e90)

The controller element supports non-disk controller types too.

https://bugzilla.redhat.com/show_bug.cgi?id=960958
(cherry picked from commit c075f89f)

(cherry picked from commit 413274f6)

Set spice password even if default VNC password hasn't been set.

https://bugzilla.redhat.com/show_bug.cgi?id=953720
(cherry picked from commit 4327df7e)

If the path part of connection URI is not present, cfg is used
unitialized.

https://bugzilla.redhat.com/show_bug.cgi?id=950855
(cherry picked from commit 74bff250)

Upstream gnulib determined that we were needlessly compiling in
gnulib's regex instead of glibc's when targetting new-enough glibc,
because the m4 test was being too strict in requiring a particular
answer to undefined behavior.
https://lists.gnu.org/archive/html/bug-gnulib/2013-04/msg00032.html

* .gnulib: Update to latest, for regex.
(cherry picked from commit 84243239)

Cherry picked because I hit a failure of test-regex when swapping
between incremental builds of libvirt.git master then v1.0.4-maint.

While this update doesn't address any reported problems in libvirt,
doing a post-release update to latest gnulib makes it easier to
stay in sync with best upstream practices.

* .gnulib: Update to latest.
* bootstrap: Resynchronize.
(cherry picked from commit d7468b7d)

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

Commit d04916fa introduced a regression in audit quality - even
though the code was computing the proper escaped name for a
path, it wasn't feeding that escaped name on to the audit message.
As a result, /var/log/audit/audit.log would mention a pair of
fields class=path path=/dev/hpet instead of the intended
class=path path="/dev/hpet", which in turn caused ausearch to
format the audit log with path=(null).

* src/conf/domain_audit.c (virDomainAuditCgroupPath): Use
constructed encoding.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 31c6bf35)

RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=949483Signed-off-by: NAlex Jia <ajia@redhat.com>
(cherry picked from commit c3e33e68)

Since commit b8a32e0e, all man pages
depend on configure.ac so that they are properly regenerated whenever
libvirt version changes. Thus libvirt.spec needs to have a build
dependency on pod2man when %{enable_autotools} is set.
(cherry picked from commit 6f1b9c8d)

By default, libtool builds two .o files for every .lo rule:
src/foo.o - static builds
src/.libs/foo.o - shared library builds

But since commit ad42b34b disabled static builds, src/foo.o is
no longer built by default.  On a fresh checkout, this means our
protocol check rules using pdwtags were testing a missing file,
and thanks to a lousy behavior of pdwtags happily giving no output
and 0 exit status (http://bugzilla.redhat.com/949034), we were
merely claiming that "dwarves is too old" and skipping the test.

However, if you swap between branches and do incremental builds,
such as building v0.10.2-maint and then switching back to master,
you end up with src/foo.o being leftover from its 0.10.2 state,
and then 'make check' fails because the .o file does not match
the protocol-structs file due to API additions in the meantime.

A simpler fix would be to always look in .libs for the .o to
be parsed; but since it is possible to pass ./configure options
to tell libtool to do a static-only build with no shared .o,
I went with the approach of finding the newest of the two files,
whenever both exist.

* src/Makefile.am (PDWTAGS): Ensure we test just-built file.
(cherry picked from commit 5899e09e)

The linker will ignore LD_PRELOAD libraries which do not
exist, just printing a warning message. This is not helpful
for the test suite which will be utterly fubar without the
preload library present. Add an explicit test for existence
of the library to protect against this
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit b1d3154a)

The last Viktor's effort to fix the race and memory corruption unfortunately
wasn't complete in the case the close callback was not registered in an
connection. At that time, the trail of event's that I'll describe later could
still happen and corrupt the memory or cause a crash of the client (including
the daemon in case of a p2p migration).

Consider the following prerequisities and trail of events:
Let's have a remote connection to a hypervisor that doesn't have a close
callback registered and the client is using the event loop. The crash happens in
cooperation of 2 threads. Thread E is the event loop and thread W is the worker
that does some stuff. R denotes the remote client.

1.) W - The client finishes everything and sheds the last reference on the client
2.) W - The virObject stuff invokes virConnectDispose that invokes doRemoteClose
3.) W - the remote close method invokes the REMOTE_PROC_CLOSE RPC method.
4.) W - The thread is preempted at this point.
5.) R - The remote side receives the close and closes the socket.
6.) E - poll() wakes up due to the closed socket and invokes the close callback
7.) E - The event loop is preempted right before remoteClientCloseFunc is called
8.) W - The worker now finishes, and frees the conn object.
9.) E - The remoteClientCloseFunc accesses the now-freed conn object in the
        attempt to retrieve pointer for the real close callback.
10.) Kaboom, corrupted memory/segfault.

This patch tries to fix this by introducing a new object that survives the
freeing of the connection object. We can't increase the reference count on the
connection object itself or the connection would never be closed, as the
connection is closed only when the reference count reaches zero.

The new object - virConnectCloseCallbackData - is a lockable object that keeps
the pointers to the real user registered callback and ensures that the
connection callback is either not called if the connection was already freed or
that the connection isn't freed while this is being called.
(cherry picked from commit 8ad126e6)

This patch improves the error message after disconnecting from the
hypervisor and adds the close callback operations required not to leak
the callback reference.
(cherry picked from commit 69ab0756)

The function is used to establish connection so it should be in the main
virsh file. This movement also enables further improvements done in next
patches.

Note that the "connect" command has moved from the host section of virsh to the
main section. It is now listed by 'virsh help virsh' instead of 'virsh help
host'.
(cherry picked from commit ca9e73eb)

Before closing the connection we unregister the close callback
to prevent a reference leak.

Further, the messages on virConnectClose != 0 are a bit more specific
now.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
(cherry picked from commit e964ba27)

By adjusting the reference count of the connection object we
prevent races between callback function and virConnectClose.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
(cherry picked from commit 03a43efa)

When creating a logical volume with virStorageVolCreateXMLFrom,
"qemu-img convert" is called internally if clonevol is a file volume.
Then, vol->target.format is used as output_fmt parameter but the
target.format of logical volumes is always 0 because logical volumes
haven't the volume format type element.

Fortunately, 0 was treated as RAW file format before commit f772b3d9,
so there was no problem. But now, 0 is treated as the type of none,
qemu-img fails with "Unknown file format 'none'".

This patch fixes this issue by treating output block devices as RAW
file format like for input block devices.
Signed-off-by: NAtsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
(cherry picked from commit d369e508)

By passing the flags -z relro -z now to the linker, we can force
it to resolve all library symbols at startup, instead of on-demand.
This allows it to then make the global offset table (GOT) read-only,
which makes some security attacks harder.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit fc8c1787)

PIE (position independent executable) adds security to executables
by composing them entirely of position-independent code (PIC. The
.so libraries already build with -fPIC. This adds -fPIE which is
the equivalent to -fPIC, but for executables. This for allows Exec
Shield to use address space layout randomization to prevent attackers
from knowing where existing executable code is during a security
attack using exploits that rely on knowing the offset of the
executable code in the binary, such as return-to-libc attacks.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 1150999c)

Mimic the fix done in 02b90972 to fix crash by
accessing an already freed structure. Also copy the explaining comment why the
pointer can't be accessed any more.
(cherry picked from commit 43b6f304)

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

The virsh domfstrim command was not freeing allocated domain,
leaving leaked references behind.
(cherry picked from commit deb86ee9)

Reported by Anthony Messina in
https://bugzilla.redhat.com/show_bug.cgi?id=904692
Present since introduction of smartcard support in commit f5fd9baa

* src/qemu/qemu_command.c (qemuBuildCommandLine): Match qemu spelling.
* tests/qemuxml2argvdata/qemuxml2argv-smartcard-host-certificates.args:
Fix broken test.
(cherry picked from commit 6f7e4ea3)

Code added by commit id '523207fe'

TEST: qemuxml2argvtest
      ........................................ 40
      ........................................ 80
      ........................................ 120
      ........................................ 160
      ........................................ 200
      ........................................ 240
      .................................        273 OK
==30993== 39 bytes in 1 blocks are definitely lost in loss record 33 of 87
==30993==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==30993==    by 0x41E501: fakeSecretGetValue (qemuxml2argvtest.c:33)
==30993==    by 0x427591: qemuBuildDriveURIString (qemu_command.c:2571)
==30993==    by 0x42C502: qemuBuildDriveStr (qemu_command.c:2627)
==30993==    by 0x4335FC: qemuBuildCommandLine (qemu_command.c:6443)
==30993==    by 0x41E8A0: testCompareXMLToArgvHelper (qemuxml2argvtest.c:154
==30993==    by 0x41FE8F: virtTestRun (testutils.c:157)
==30993==    by 0x418BE3: mymain (qemuxml2argvtest.c:506)
==30993==    by 0x4204CA: virtTestMain (testutils.c:719)
==30993==    by 0x38D6821A04: (below main) (in /usr/lib64/libc-2.16.so)
==30993==
==30993== 46 bytes in 1 blocks are definitely lost in loss record 64 of 87
==30993==    at 0x4A0887C: malloc (vg_replace_malloc.c:270)
==30993==    by 0x38D690A167: __vasprintf_chk (in /usr/lib64/libc-2.16.so)
==30993==    by 0x4CB28E7: virVasprintf (stdio2.h:210)
==30993==    by 0x4CB29A3: virAsprintf (virutil.c:2017)
==30993==    by 0x4275B4: qemuBuildDriveURIString (qemu_command.c:2580)
==30993==    by 0x42C502: qemuBuildDriveStr (qemu_command.c:2627)
==30993==    by 0x4335FC: qemuBuildCommandLine (qemu_command.c:6443)
==30993==    by 0x41E8A0: testCompareXMLToArgvHelper (qemuxml2argvtest.c:154
==30993==    by 0x41FE8F: virtTestRun (testutils.c:157)
==30993==    by 0x418BE3: mymain (qemuxml2argvtest.c:506)
==30993==    by 0x4204CA: virtTestMain (testutils.c:719)
==30993==    by 0x38D6821A04: (below main) (in /usr/lib64/libc-2.16.so)
==30993==
==30993== 385 (56 direct, 329 indirect) bytes in 1 blocks are definitely los
==30993==    at 0x4A06B6F: calloc (vg_replace_malloc.c:593)
==30993==    by 0x4C6B2CF: virAllocN (viralloc.c:152)
==30993==    by 0x4C9C7EB: virObjectNew (virobject.c:191)
==30993==    by 0x4D21810: virGetSecret (datatypes.c:642)
==30993==    by 0x41E5D5: fakeSecretLookupByUsage (qemuxml2argvtest.c:51)
==30993==    by 0x4D4BEC5: virSecretLookupByUsage (libvirt.c:15295)
==30993==    by 0x4276A9: qemuBuildDriveURIString (qemu_command.c:2565)
==30993==    by 0x42C502: qemuBuildDriveStr (qemu_command.c:2627)
==30993==    by 0x4335FC: qemuBuildCommandLine (qemu_command.c:6443)
==30993==    by 0x41E8A0: testCompareXMLToArgvHelper (qemuxml2argvtest.c:154
==30993==    by 0x41FE8F: virtTestRun (testutils.c:157)
==30993==    by 0x418BE3: mymain (qemuxml2argvtest.c:506)
==30993==
PASS: qemuxml2argvtest

Interesting side note is that running the test singularly via 'make -C tests
check TESTS=qemuxml2argvtest' didn't trip the valgrind error; however,
running during 'make -C tests valgrind' did cause the error to be seen.
(cherry picked from commit 9a80050e)

Commit 9a3ff01d (which was ACKed at
the end of January, but for some reason didn't get pushed until during
the 1.0.4 freeze) fixed the logic in virPCIGetVirtualFunctions().
Unfortunately, a typo in the fix (replacing VIR_REALLOC_N with
VIR_ALLOC_N during code movement) caused not only a memory leak, but
also resulted in most of the elements of the result array being
replaced with NULL. virNetDevGetVirtualFunctions() assumed (and I think
rightly so) that virPCIGetVirtualFunctions() wouldn't return any NULL
elements in the array, so it ended up segfaulting.

This was found when attempting to use a virtual network with an
auto-created pool of SRIOV VFs, e.g.:

    <forward mode='hostdev' managed='yes'>
      <pf dev='eth4'/>
    </forward>

(the pool of PCI addresses is discovered by calling
virNetDevGetVirtualFunctions() on the PF dev).

- configure.ac docs/news.html.in libvirt.spec.in: updates for the release
- po/*.po*: fetch translation updates from Transifex and regenerate