Some of the Xen sub-drivers have checks against the
VIR_CONNECT_RO flag. This is not required, since such
checks are done at the top level before the driver
methods are invoked
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The Xen hypervisor driver checks for 'priv->handle < 0' and
returns -1, but without raising any error. Fortunately this
code will never be executed, since the main Xen driver always
checks 'priv->opened[XEN_UNIFIED_HYPERVISOR_OFFSET]' prior
to invoking any hypervisor API. Just remove the redundant
checks for priv->handle
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The udevFreeIfaceDef function in the udev interface driver
just duplicates code from virInterfaceDefFree. Delete it
and call the standard API instead.

Fix the udevGetIfaceDefVlan method so that it doesn't
store pointers to the middle of a malloc'd memory
area.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Pushed under trivial rule

Pushed under trivial rule.

Among others, this fixes a cosmetic bug where bootstrap stated:

./bootstrap: Bootstrapping from checked-out http://libvirt.org sources...

instead of the intended:

./bootstrap: Bootstrapping from checked-out libvirt sources...

* .gnulib: Update to latest, for bootstrap improvement.
* bootstrap: Resync from gnulib.

Recent commit '53531e16' resulted in a new Coverity warning regarding
a missing break in the ':' options processing. Adjust the commit to
avoid the issue.

The LXC, QEMU, and LibXL drivers have all merged their handling of
the attach/update/modify device APIs into one large

  'xxxxDomainModifyDeviceFlags'

which then does a 'switch()' based on the actual API being invoked.
While this saves some lines of code, it is not really all that
significant in the context of the driver API impls as a whole.

This merger of the handling of different APIs creates pain when
wanting to automated analysis of the code and do things which
are specific to individual APIs. The slight duplication of code
from unmerged the API impls, is preferrable to allow for easier
automated analysis.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Currently the parsing of XML is pushed down into the various
migration helper APIs. This makes it difficult to insert the
correct access control checks, since one helper API services
many public APIs. Pull the parsing of XML up to the top level
of the QEMU driver APIs

Several APIs allow for custom XML to be passed in. This is
checked for ABI stability, which will ensure the UUID is
not being changed. There isn't validation that the name
did not change though. This could allow renaming of guests
via the backdoor, which in turn could allow for bypassing
access control restrictions based on names.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

In renaming driver API implementations to match the
public API naming scheme, a few cases in the node
device driver were missed.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The individual hypervisor drivers were directly referencing
APIs in virnodesuspend.c in their virDriverPtr struct. Separate
these methods, so there is always a wrapper in the hypervisor
driver. This allows the unused virConnectPtr args to be removed
from the virnodesuspend.c file. Again this will ensure that
ACL checks will only be performed on invocations that are
directly associated with public API usage.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The individual hypervisor drivers were directly referencing
APIs in src/nodeinfo.c in their virDriverPtr struct. Separate
these methods, so there is always a wrapper in the hypervisor
driver. This allows the unused virConnectPtr args to be
removed from the nodeinfo.c file. Again this will ensure that
ACL checks will only be performed on invocations that are
directly associated with public API usage.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Currently the virGetHostname() API has a bogus virConnectPtr
parameter. This is because virtualization drivers directly
reference this API in their virDriverPtr tables, tieing its
API design to the public virConnectGetHostname API design.

This also causes problems for access control checks since
these must only be done for invocations from the public
API, not internal invocation.

Remove the bogus virConnectPtr parameter, and make each
hypervisor driver provide a dedicated function for the
driver API impl. This will allow access control checks
to be easily inserted later.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

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>

There are various methods named "virXXXXSecurityContext",
which are specific to SELinux. Rename them all to
"virXXXXSELinuxContext". They will still raise errors at
runtime if SELinux is not compiled in
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

It is possible for $line to be undefined at first used, if
the symfile doesn't have a section prefix (which is the case
for auto-generated symfiles).
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

If the volume is of a clustered volume group, and not active, the
related pool APIs fails on opening /dev/vg/lv. If the volume is
suspended, it hangs on open(2) the volume.

Though the best solution is to expose the volume status in volume
XML, and even better to provide API to activate/deactivate the volume,
but it's not the work I want to touch currently. Volume status in
other status is just fine to skip.

About the 5th field of lv_attr (from man lvs[8])
<quote>
 5 State: (a)ctive, (s)uspended, (I)nvalid snapshot, invalid
   (S)uspended snapshot, snapshot (m)erge failed,suspended
   snapshot (M)erge failed, mapped (d)evice present without
   tables,  mapped device present with (i)nactive table
</quote>

While reviewing proposed VIR_STRDUP conversions, I've already noticed
several places that do:

if (str && VIR_STRDUP(dest, str) < 0)

which can be simplified by allowing str to be NULL (something that
strdup() doesn't allow).  Meanwhile, code that wants to ensure a
non-NULL dest regardless of the source can check for <= 0.

Also, make it part of the VIR_STRDUP contract that macro arguments
are evaluated exactly once.

* src/util/virstring.h (VIR_STRDUP, VIR_STRDUP_QUIET, VIR_STRNDUP)
(VIR_STRNDUP_QUIET): Improve contract.
* src/util/virstring.c (virStrdup, virStrndup): Change return
conventions.
* docs/hacking.html.in: Document this.
* HACKING: Regenerate.
Signed-off-by: NEric Blake <eblake@redhat.com>

VIR_APPEND_ELEMENT(array, size, elem) was not safe if the expression
for 'size' had side effects.  While no one in the current code base
was trying to pass side effects, we might as well be robust and
explicitly document our intentions.

* src/util/viralloc.c (virInsertElementsN): Add special case.
* src/util/viralloc.h (VIR_APPEND_ELEMENT): Use it.
(VIR_ALLOC, VIR_ALLOC_N, VIR_REALLOC_N, VIR_EXPAND_N)
(VIR_RESIZE_N, VIR_SHRINK_N, VIR_INSERT_ELEMENT)
(VIR_DELETE_ELEMENT, VIR_ALLOC_VAR, VIR_FREE): Document
which macros are safe in the presence of side effects.
* docs/hacking.html.in: Document this.
* HACKING: Regenerate.
Signed-off-by: NEric Blake <eblake@redhat.com>

Use virBufferAddLit or virBufferAddChar instead.

VFIO device assignment requires a cgroup ACL to be setup for access to
the /dev/vfio/nn "group" device for any devices that will be assigned
to a guest. In the case of a host device that is allocated from a
pool, it was being allocated during qemuBuildCommandLine(), which is
called by qemuProcessStart() *after* the all-encompassing
qemuSetupCgroup() was called, meaning that the standard Cgroup ACL
setup wasn't creating ACLs for these devices allocated from pools.

One possible solution was to manually add a single ACL down inside
qemuBuildCommandLine() when networkAllocateActualDevice() is called,
but that has two problems: 1) the function that adds the cgroup ACL
requires a virDomainObjPtr, which isn't available in
qemuBuildCommandLine(), and 2) we really shouldn't be doing network
device setup inside qemuBuildCommandLine() anyway.

Instead, I've created a new function called
qemuNetworkPrepareDevices() which is called just before
qemuPrepareHostDevices() during qemuProcessStart() (explanation of
ordering in the comments), i.e. well before the call to
qemuSetupCgroup(). To minimize code churn in a patch that will be
backported to 1.0.5-maint, qemuNetworkPrepareDevices only does
networkAllocateActualDevice() and the bare amount of setup required
for type='hostdev network devices, but it eventually should do *all*
device setup for guest network devices.

Note that some of the code that was previously needed in
qemuBuildCommandLine() is no longer required when
networkAllocateActualDevice() is called earlier:

 * qemuAssignDeviceHostdevAlias() is already done further down in
   qemuProcessStart().

 * qemuPrepareHostdevPCIDevices() is called by
   qemuPrepareHostDevices() which is called after
   qemuNetworkPrepareDevices() in qemuProcessStart().

As hinted above, this new function should be moved into a separate
qemu_network.c (or similarly named) file along with
qemuPhysIfaceConnect(), qemuNetworkIfaceConnect(), and
qemuOpenVhostNet(), and expanded to call those functions as well, then
the nnets loop in qemuBuildCommandLine() should be reduced to only
build the commandline string (which itself can be in a separate
qemuInterfaceBuilldCommandLine() function as suggested by
Michal). However, this will require storing away an array of tapfd and
vhostfd that are needed for the commandline, so I would rather do that
in a separate patch and leave this patch at the minimum to fix the
bug.