CVE-2016-5008

Setting an empty graphics password is documented as a way to disable
VNC/SPICE access, but QEMU does not always behaves like that. VNC would
happily accept the empty password. Let's enforce the behavior by setting
password expiration to "now".

https://bugzilla.redhat.com/show_bug.cgi?id=1180092Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
(cherry picked from commit bb848fee)
(cherry picked from commit d933f68e)

The libvirt file system storage driver determines what file to
act on by concatenating the pool location with the volume name.
If a user is able to pick names like "../../../etc/passwd", then
they can escape the bounds of the pool.  For that matter,
virStoragePoolListVolumes() doesn't descend into subdirectories,
so a user really shouldn't use a name with a slash.

Normally, only privileged users can coerce libvirt into creating
or opening existing files using the virStorageVol APIs; and such
users already have full privilege to create any domain XML (so it
is not an escalation of privilege).  But in the case of
fine-grained ACLs, it is feasible that a user can be granted
storage_vol:create but not domain:write, and it violates
assumptions if such a user can abuse libvirt to access files
outside of the storage pool.

Therefore, prevent all use of volume names that contain "/",
whether or not such a name is actually attempting to escape the
pool.

This changes things from:

$ virsh vol-create-as default ../../../../../../etc/haha --capacity 128
Vol ../../../../../../etc/haha created
$ rm /etc/haha

to:

$ virsh vol-create-as default ../../../../../../etc/haha --capacity 128
error: Failed to create vol ../../../../../../etc/haha
error: Requested operation is not valid: volume name '../../../../../../etc/haha' cannot contain '/'
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 034e47c3)

Since commit 8eb55d782a2b9afacc7938694891cc6fad7b42a5 libxml2 removes
two slashes from the URI when there is no server part.  This is fixed
with beb7281055dbf0ed4d041022a67c6c5cfd126f25, but only if the calling
application calls xmlSaveUri() on URI that xmlURIParse() parsed.  And
that is not the case in virURIFormat().  virURIFormat() accepts
virURIPtr that can be created without parsing it and we do that when we
format network storage paths for gluster for example.  Even though
virStorageSourceParseBackingURI() uses virURIParse(), it throws that data
structure right away.

Since we want to format URIs as URIs and not absolute URIs or opaque
URIs (see RFC 3986), we can specify that with a special hack thanks to
commit beb7281055dbf0ed4d041022a67c6c5cfd126f25, by setting port to -1.

This fixes qemuxml2argvtest test where the disk-drive-network-gluster
case was failing.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
(cherry picked from commit 8f17d0ea)

In systemd >= 218, the udev_set_log_fn method has been marked
deprecated and turned into a no-op. Nothing in the udev client
library will print to stderr by default anymore, so we can
just stop installing a logging hook for new enough udev.

(cherry picked from commit a93a3b97)

The call to virDomainSnapshotRedefinePrep() had a spurrious ! in front of
it which caused Coverity to complan that the expression is always false.

(cherry picked from commit 9d7254de)

It returns NULL on failure. Checking if the negation of it
is less than zero makes no sense. (Found by coverity after moving
the code)

In another case, the return value wasn't checked at all.

(cherry picked from commit 3fe9d75a)

Conflicts:
	src/conf/domain_addr.c - no code movement from commit b2626755

libxl interface for vcpu pinning is changing in Xen 4.5. Basically,
libxl_set_vcpuaffinity() now wants one more parameter. That is
representative of 'VCPU soft affinity', which libvirt does not use.

To mark such change, the macro LIBXL_HAVE_VCPUINFO_SOFT_AFFINITY is
defined. Use it as a gate and, if present, re-#define the calls from
the old to the new interface, to avoid breaking the build.
Signed-off-by: NDario Faggioli <dario.faggioli@citrix.com>
Cc: Jim Fehlig <jfehlig@suse.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
(cherry picked from commit bfc72e99)

Well, in 8ad126e6 we tried to fix a memory corruption problem.
However, the fix was not as good as it could be. I mean, the
commit has one line more than it should. I've noticed this output
just recently:

  # ./run valgrind --leak-check=full --show-reachable=yes ./tools/virsh domblklist gentoo
  ==17019== Memcheck, a memory error detector
  ==17019== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
  ==17019== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
  ==17019== Command: /home/zippy/work/libvirt/libvirt.git/tools/.libs/virsh domblklist gentoo
  ==17019==
  Target     Source
  ------------------------------------------------
  fda        /var/lib/libvirt/images/fd.img
  vda        /var/lib/libvirt/images/gentoo.qcow2
  hdc        /home/zippy/tmp/install-amd64-minimal-20150402.iso

  ==17019== Thread 2:
  ==17019== Invalid read of size 4
  ==17019==    at 0x4EFF5B4: virObjectUnref (virobject.c:258)
  ==17019==    by 0x5038CFF: remoteClientCloseFunc (remote_driver.c:552)
  ==17019==    by 0x5069D57: virNetClientCloseLocked (virnetclient.c:685)
  ==17019==    by 0x506C848: virNetClientIncomingEvent (virnetclient.c:1852)
  ==17019==    by 0x5082136: virNetSocketEventHandle (virnetsocket.c:1913)
  ==17019==    by 0x4ECD64E: virEventPollDispatchHandles (vireventpoll.c:509)
  ==17019==    by 0x4ECDE02: virEventPollRunOnce (vireventpoll.c:658)
  ==17019==    by 0x4ECBF00: virEventRunDefaultImpl (virevent.c:308)
  ==17019==    by 0x130386: vshEventLoop (vsh.c:1864)
  ==17019==    by 0x4F1EB07: virThreadHelper (virthread.c:206)
  ==17019==    by 0xA8462D3: start_thread (in /lib64/libpthread-2.20.so)
  ==17019==    by 0xAB441FC: clone (in /lib64/libc-2.20.so)
  ==17019==  Address 0x139023f4 is 4 bytes inside a block of size 240 free'd
  ==17019==    at 0x4C2B1F0: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
  ==17019==    by 0x4EA8949: virFree (viralloc.c:582)
  ==17019==    by 0x4EFF6D0: virObjectUnref (virobject.c:273)
  ==17019==    by 0x4FE74D6: virConnectClose (libvirt.c:1390)
  ==17019==    by 0x13342A: virshDeinit (virsh.c:406)
  ==17019==    by 0x134A37: main (virsh.c:950)

The problem is, when registering remoteClientCloseFunc(), it's
conn->closeCallback which is ref'd. But in the function itself
it's conn->closeCallback->conn what is unref'd. This is causing
imbalance in reference counting. Moreover, there's no need for
the remote driver to increase/decrease conn refcount since it's
not used anywhere. It's just merely passed to client registered
callback. And for that purpose it's correctly ref'd in
virConnectRegisterCloseCallback() and then unref'd in
virConnectUnregisterCloseCallback().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit e6893007)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The function is called from all {Attach,Update,Detach}Device APIs to
create config strings that are later passed to the xend to perform the
desired action. The function is intended to handle all supported
devices. However, as of 5b05358a we
are trying to get disk driver of the device without checking if the
device really is a disk. This leads to an segmentation fault:

  #0 0x00007ffff7571815 in virDomainDiskGetDriver () from /usr/lib/libvirt.so.0
  #1 0x00007fffeb9ad471 in ?? () from /usr/lib/libvirt/connection-driver/libvirt_driver_xen.so
  #2 0x00007fffeb9b1062 in xenDaemonAttachDeviceFlags () from /usr/lib/libvirt/connection-driver/libvirt_driver_xen.so
  #3 0x00007fffeb9a8a86 in ?? () from /usr/lib/libvirt/connection-driver/libvirt_driver_xen.so
  #4 0x00007ffff7609266 in virDomainAttachDevice () from /usr/lib/libvirt.so.0
  #5 0x0000555555593c9d in ?? ()
  #6 0x00007ffff76743c9 in virNetServerProgramDispatch () from /usr/lib/libvirt.so.0
  #7 0x00005555555a678d in ?? ()
  #8 0x00007ffff755460e in ?? () from /usr/lib/libvirt.so.0
  #9 0x00007ffff7553b06 in ?? () from /usr/lib/libvirt.so.0
  #10 0x00007ffff4998b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
  #11 0x00007ffff46e30ed in clone () from /lib/x86_64-linux-gnu/libc.so.6
  #12 0x0000000000000000 in ?? ()
Reported-by: NXiaolin Su <linxxnil@126.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit cd7702d4)

The ACL check didn't check the VIR_DOMAIN_XML_SECURE flag and the
appropriate permission for it. Found via code inspection while fixing
permissions for save images.

(cherry picked from commit b347c0c2)

The ACL check didn't check the VIR_DOMAIN_XML_SECURE flag and the
appropriate permission for it.

(cherry picked from commit 03c3c0c8)

Avoid leaving the domain locked on a failed ACL check in
qemuDomainMigratePerform() and qemuDomainMigrateFinish2().

Introduced in commit abf75aea (Add ACL checks into the QEMU driver).

(cherry picked from commit 2bdcd29c)

https://bugs.gentoo.org/show_bug.cgi?id=508336

At wireshark, they have this promise to change public dissector APIs
only with minor version number change. Which they did when releasing
the version of 1.12.

Firstly, they've changed tvb_memdup() in
a0c53ffaa1bb46d8c9db2ec739401aa411c9790e so now it takes four arguments
instead of three. The new argument is placed at the very beginning of
the list of arguments and basically says the scope where we'd like to
allocate the memory. According to the documentation NULL should be the
default value.

Then, the tcp_dissect_pdus() signature changed too. Well, the function
that actually dissects reassembled packets as tcp_dissect_pdus()
reorder TCP packets into one big chunk and then calls a user function
to dissect the PDU at once. The change is dated back to
8081cf1d90397cbbb4404f9720595e1537ed5e14.

Then, WS_DLL_PUBLIC_NOEXTERN was replaced with WS_DLL_PUBLIC_DEF in
5d87a8c46171f572568db5a47c093423482e342f.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit e74fa570)

The rationale is to not duplicate code which is done in
packet-libvirt.h for instance. Moreover, this way we can drop
__attribute_((unused)) used int packet-libvirt.c in favor of
ATTRIBUTE_UNUSED.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
(cherry picked from commit 906d0abf)

virNetDevLinkDump() gets a message from netlink into "resp", then
calls nlmsg_parse() to fill the table "tb" with pointers into resp. It
then returns tb to its caller, but not before freeing the buffer at
resp. That means that all the callers of virNetDevLinkDump() are
examining memory that has already been freed. This can be verified by
filling the buffer at resp with garbage prior to freeing it (or, I
suppose, just running libvirtd under valgrind) then performing some
operation that calls virNetDevLinkDump().

The upstream commit log incorrectly states that the code has been like
this ever since virNetDevLinkDump() was written. In reality, the
problem was introduced with commit e95de74d, first in libvirt-1.0.5,
which was attempting to eliminate a typecast that caused compiler
warnings. It has only been pure luck (or maybe a lack of heavy load,
and/or maybe an allocation algorithm in malloc() that delays re-use of
just-freed memory) that has kept this from causing errors, for example
when configuring a PCI passthrough or macvtap passthrough network
interface.

The solution taken in this patch is the simplest - just return resp to
the caller along with tb, then have the caller free it after they are
finished using the data (pointers) in tb. I alternately could have
made a cleaner interface by creating a new struct that put tb and resp
together along with a vir*Free() function for it, but this function is
only used in a couple places, and I'm not sure there will be
additional new uses of virNetDevLinkDump(), so the value of adding a
new type, extra APIs, etc. is dubious.

(cherry picked from commit f9f9699f)

Commit 28f8dfdc (v1.0.0) introduced a security hole: in at least
the qemu implementation of virDomainGetXMLDesc, the use of the
flag VIR_DOMAIN_XML_MIGRATABLE (which is usable from a read-only
connection) triggers the implicit use of VIR_DOMAIN_XML_SECURE
prior to calling qemuDomainFormatXML.  However, the use of
VIR_DOMAIN_XML_SECURE is supposed to be restricted to read-write
clients only.  This patch treats the migratable flag as requiring
the same permissions, rather than analyzing what might break if
migratable xml no longer includes secret information.

Fortunately, the information leak is low-risk: all that is gated
by the VIR_DOMAIN_XML_SECURE flag is the VNC connection password;
but VNC passwords are already weak (FIPS forbids their use, and
on a non-FIPS machine, anyone stupid enough to trust a max-8-byte
password sent in plaintext over the network deserves what they
get).  SPICE offers better security than VNC, and all other
secrets are properly protected by use of virSecret associations
rather than direct output in domain XML.

* src/remote/remote_protocol.x (REMOTE_PROC_DOMAIN_GET_XML_DESC):
Tighten rules on use of migratable flag.
* src/libvirt-domain.c (virDomainGetXMLDesc): Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit b1674ad5)

Conflicts:
	src/libvirt-domain.c - file split from older src/libvirt.c
Signed-off-by: NEric Blake <eblake@redhat.com>

If you use public api virConnectListAllDomains() with second parameter
set to NULL to get only the number of domains you will lock out all
other operations with domains.

Introduced by commit 2c680804.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
(cherry picked from commit fc22b2e7)

Live definition was used to look up the disk index while persistent one
was indexed leading to a crash in qemuDomainGetBlockIoTune. Use the
correct def and report a nice error.

Unfortunately it's accessible via read-only connection, though it can
only crash libvirtd in the cases where the guest is hot-plugging disks
without reflecting those changes to the persistent definition.  So
avoiding hotplug, or doing hotplug where persistent is always modified
alongside live definition, will avoid the out-of-bounds access.

Introduced in: eca96694a (v0.9.8)
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1140724Reported-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

(cherry picked from commit 3e745e8f)

We have the following matrix of possible arguments handled by the logic
statement touched by this patch:
       | flags & _REUSE_EXT | !(flags & _REUSE_EXT)
-------+--------------------+----------------------
 format| (1)                | (2)
-------+--------------------+----------------------
!format| (3)                | (4)
-------+--------------------+----------------------

In cases 1 and 2 the user provided a format, in cases 3 and 4 not. The
user requests to use a pre-existing image in 1 and 3 and libvirt will
create a new image in 2 and 4.

The difference between cases 3 and 4 is that for 3 the format is probed
from the user-provided image, whereas in 4 we just use the existing disk
format.

The current code would treat cases 1,3 and 4 correctly but in case 2 the
format provided by the user would be ignored.

The particular piece of code was broken in commit 35c7701c
but since it was introduced a few commits before that it was never
released as working.

(cherry picked from commit 42619ed0)
Signed-off-by: NEric Blake <eblake@redhat.com>

Conflicts:
	src/qemu/qemu_driver.c - no refactoring of commit 7b7bf001

libvirt unit test used setxattr with "user.libvirt.selinux" name to
emulate setfilecon of selinux. But for some old kernel filesystem
(like 2.6.32-431.el6.x86_64), if the filesystem is not mounted with
user_xattr flag, the setxattr with "user.libvirt.selinux" will fail.

So adding testUserXattrEnabled() in securityselinuxlabeltest.c,
if user_xattr is not enabled, skip this case.

The user_xattr is departed in newer kernel, therefore this commit is
only for the compatablity for old kernel.
Signed-off-by: NJincheng Miao <jmiao@redhat.com>
Signed-off-by: NEric Blake <eblake@redhat.com>
Tested-by: NScott Sullivan <ssullivan@liquidweb.com>
(cherry picked from commit caf164f1)

We publish libvirt-api.xml for others to use, and in fact, the
libvirt-python bindings use it to generate python constants that
correspond to our enum values.  However, we had an off-by-one bug
that any enum that relied on C's rules for implicit initialization
of the first enum member to 0 got listed in the xml as having a
value of 1 (and all later members of the enum were equally
botched).

The fix is simple - since we add one to the previous value when
encountering an enum without an initializer, the previous value
must start at -1 so that the first enum member is assigned 0.

The python generator code has had the off-by-one ever since DV
first wrote it years ago, but most of our public enums were immune
because they had an explicit = 0 initializer.  The only affected
enums are:
- virDomainEventGraphicsAddressType (such as
VIR_DOMAIN_EVENT_GRAPHICS_ADDRESS_IPV4), since commit 987e31ed
(libvirt v0.8.0)
- virDomainCoreDumpFormat (such as VIR_DOMAIN_CORE_DUMP_FORMAT_RAW),
since commit 9fbaff00 (libvirt v1.2.3)
- virIPAddrType (such as VIR_IP_ADDR_TYPE_IPV4), since commit
03e0e79e (not yet released)

Thanks to Nehal J Wani for reporting the problem on IRC, and
for helping me zero in on the culprit function.

* docs/apibuild.py (CParser.parseEnumBlock): Fix implicit enum
values.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 9b291bbe)

When creating a new disk mirror the new struct is stored in a separate
variable until everything went well. The removed hunk would actually
remove existing mirror information for example when the api would be run
if a mirror still exists.

(cherry picked from commit 02b364e1)

This fixes a regression introduced in commit ff5f30b6.
Signed-off-by: NEric Blake <eblake@redhat.com>

Conflicts:
	src/qemu/qemu_driver.c - no refactoring of commit 7b7bf001

Jim Fehlig reported a regression found by libvirt-TCK tests:

> ~ # perl /usr/share/libvirt-tck/tests/qemu/100-disk-encryption.t
...
> ok 4 - defined persistent domain config
> # Starting inactive domain config
> libvirt error code: 1, message: internal error: unable to execute QEMU command
> 'cont': 'drive-ide0-0-1'
> (/var/cache/libvirt-tck/300-disk-encryption/demo.qcow2) is encrypted

Commit 2279d560 converted a boolean into a pointer with the intent of
transferring that pointer out of a temporary object into the caller's
data structure.  The temporary structure meant that meta->encryption
was always NULL on entry, so we could get away with blindly allocating
the pointer when the header said so.  But later, commit 8823272d
tweaked things to do backing chain detection in-place, rather than via
a temporary object; this has the net result that meta->encryption can
be non-NULL on entry.  Not only did this turn the latent behavior into
a memory leak, it is also a behavior regression: blindly allocating a
new pointer wipes out what secrets we already knew about the chain,
making it impossible to restart the domain.

Of course, no one in their right mind should be relying on qcow2
encryption - it is fundamentally flawed.  And sadly, the TCK tests
don't get run often enough, and this shows that our virstoragetest
does not exercise encrypted images at all.  Otherwise, we could
have avoided a release containing this regression.

* src/util/virstoragefile.c (virStorageFileGetMetadataInternal):
Don't nuke an already-existing encryption.
Signed-off-by: NEric Blake <eblake@redhat.com>
(cherry picked from commit 1c7eb95c)

Commit fff74b27 moved the probing into virStorageFileGetMetadataFromBuf
but didn't update the format in volume definition.

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

Conflicts:
	src/storage/storage_backend_fs.c
      I didn't backport the refactors - febcb89c and effbb11e

* docs/news.html.in: update for release
* po/*.po*: updated ukrainian localization and regenerated

- Document 'domxml-to-native' command
- Mention that the nmdm console support needs an appropriate
  kernel module loaded

Reported by: Roman Bogorodskiy <bogorodskiy@gmail.com>

Some of the tests for virTimeLocalOffsetFromUTC set an imaginary
timezone that attempts to force dyalight savings time active all the
time by setting a start date of 0/00:00:00 and end date of
366/23:59:59. Since the day is 0-based, 366 really means "day 367"
which will never occur - this was an attempt to eliminate problems
with DST not being active in some cases right around midnight on
January 1. Even though it didn't completely solve the problem, it
didn't seem to cause harm so it was left in the test timezones.

Although Linux glibc doesn't mind having a DST end date of 366,
FreeBSD refuses to use such timezones, so the tests fail. This patch
changes the 366 to 365.

This may or may not cause failure of the remaining DST tests around
midnight Jan 1. If so, we will need to disable those tests at year's
end too.

On a 32-bit platform:

virstringtest.c: In function 'mymain':
virstringtest.c:673: warning: this decimal constant is unsigned only in ISO C90

I already had a comment in the file about the 64-bit counterpart;
the easiest fix was to make both sites use the standardized macro
that is guaranteed to work.

* tests/virstringtest.c (mymain): Minimum signed integers are a pain.
Signed-off-by: NEric Blake <eblake@redhat.com>

Currently we don't support mixed (external + internal) snapshots. The
code detecting the snapshot type didn't make sure that the memory image
was consistent with the snapshot type leading into strange error
message:

 $ virsh snapshot-create-as --domain VM --diskspec vda,snapshot=internal --memspec snapshot=external,file=/tmp/blah
 error: internal error: unexpected code path

Fix the mixed detection code to detect this kind of mistake:

 $ virsh snapshot-create-as --domain VM --diskspec vda,snapshot=internal --memspec snapshot=external,file=/tmp/blah
 error: unsupported configuration: mixing internal and external targets for a snapshot is not yet supported

A internal snapshot of a active VM with the memory snapshot disabled
explicitly would actually still take the memory snapshot. Reject it
explicitly.

Before:
 $ virsh snapshot-create-as --domain VM --diskspec vda,snapshot=internal --memspec snapshot=no
 Domain snapshot 1401353155 created

After:
 $ virsh snapshot-create-as --domain VM --diskspec vda,snapshot=internal --memspec snapshot=no
 error: Operation not supported: internal snapshot of a running VM must include the memory state

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

For guests backed by gluster volumes (or other network storage) we don't
fill the backing chain (see qemuDomainDetermineDiskChain). This leaves
the "relPath" field of the top image NULL. This causes a crash in
virStorageFileChainLookup() when looking up a backing element for such a
disk.

Since I'm working on adding support for network storage and one of the
steps will make the "relPath" field optional let's use STREQ_NULLABLE
instead of STREQ in virStorageFileChainLookup() to avoid the problem.

The original version of virTimeLocalOffsetFromUTC() would fail for
certain times of the day if daylight savings time was active. This
could most easily be seen by uncommenting the TEST_LOCALOFFSET() cases
that include a DST setting.

After a lot of experimenting, I found that the way to solve it in
almost all test cases is to set tm_isdst = -1 in the struct tm prior
to calling mktime(). Once this is done, the correct offset is returned
for all test cases at all times except the two hours just after
00:00:00 Jan 1 UTC - during that time, any timezone that is *behind*
UTC, and that is supposed to always be in DST will not have DST
accounted for in its offset.

I believe that the code of virTimeLocalOffsetFromUTC() actually is
correct for all cases, but the problem still encountered is due to our
inability to come up with a TZ string that properly forces DST to
*always* be active. Since a modfication of the (currently fixed)
expected result data to account for this would necessarily use the
same functions that we're trying to test, I've instead just made the
test program conditionally bypass the problematic cases if the current
date is either December 31 or January 1. This way we get maximum
testing during 363 days of the year, but don't get false failures on
Dec 31 and Jan 1.

* tools/virsh.pod (attach-disk): Drop duplicate --config, fix typo
in --sourcetype.
Signed-off-by: NEric Blake <eblake@redhat.com>

Use correct variable name.

* m4/virt-selinux.m4: Fix one last variable name.

Commit 292d3f2d fixed the build with libselinux 2.3, but missed
some suggestions by eblake

https://www.redhat.com/archives/libvir-list/2014-May/msg00977.html

This patch changes the macro introduced in 292d3f2d to either be
empty in the case of newer libselinux, or contain 'const' in the
case of older libselinux.  The macro is then used directly in
tests/securityselinuxhelper.c.

Several function signatures changed in libselinux 2.3, now taking
a 'const char *' instead of 'security_context_t'.  The latter is
defined in selinux/selinux.h as

  typedef char *security_context_t;
Signed-off-by: NEric Blake <eblake@redhat.com>

Even successful start of a VM from a managed save image would spam the
logs with the following message:

Unable to restore from managed state [path]. Maybe the file is
corrupted?

Re-arrange the logic to output the warning only when the image is
corrupted.

The flaw was introduced in commit cfc28c66.

Now that virStorageFileGetMetadataFromBuf is used only for remote
filesystems, don't canonicalize the path in it.

Use virStorageFileGetMetadataFromFD instead in
virStorageBackendProbeTarget as it now returns all required data and the
storage file is already open in a filedescriptor.

Also fix improper error code being returned when virFileReadHeaderFD
would fail as virStorageBackendUpdateVolTargetInfoFD would set the
return code to 0.

Add argument to return backing file format of a file probed by
virStorageFileGetMetadataFromFD so that it can be used in place of
virStorageFileGetMetadataFromBuf.