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

When the login session doesn't have an ssh -X type display agent in
order for libvirtd to run the polkit session authentication, attempts
to run 'virsh -c qemu:///system list' from an unauthorized user (or one
that isn't part of the libvirt /etc/group) will fail with the following
error from libvirtd:

error: authentication unavailable: no polkit agent available to
       authenticate action 'org.libvirt.unix.manage'

In order to handle the local authentication, we will use the new
virPolkitAgentCreate API in order to create a text based authentication
agent for our non readonly session to authenticate with.

The new code will execute in a loop allowing 5 failures to authenticate
before failing out.

With this patch in place, the following occurs:

$ virsh -c qemu:///system list
==== AUTHENTICATING FOR org.libvirt.unix.manage ===
System policy prevents management of local virtualized systems
Authenticating as: Some User (SUser)
Password:
==== AUTHENTICATION COMPLETE ===
 Id    Name                           State
 ----------------------------------------------------
  1     somedomain                     running

$

Introduce virPolkitAgentCreate and virPolkitAgentDestroy

virPolkitAgentCreate will run the polkit pkttyagent image as an asynchronous
command in order to handle the local agent authentication via stdin/stdout.
The code makes use of the pkttyagent --notify-fd mechanism to let it know
when the agent is successfully registered.

virPolkitAgentDestroy will close the command effectively reaping our
child process

When there isn't a ssh -X type session running and a user has not
been added to the libvirt group, attempts to run 'virsh -c qemu:///system'
commands from an otherwise unprivileged user will fail with rather
generic or opaque error message:

    "error: authentication failed: no agent is available to authenticate"

This patch will adjust the error code and message to help reflect the
situation that the problem is the requested mechanism is UNAVAILABLE and
a slightly more descriptive error. The result on a failure then becomes:

    "error: authentication unavailable: no polkit agent available to
            authenticate action 'org.libvirt.unix.manage'"

A bit more history on this - at one time a failure generated the
following type message when running the 'pkcheck' as a subprocess:

"error: authentication failed: polkit\56retains_authorization_after_challenge=1
Authorization requires authentication but no agent is available."

but, a patch was generated to adjust the error message to help provide
more details about what failed. This was pushed as commit id '96a108c9'.
That patch prepended a "polkit: " to the output. It really didn't solve
the problem, but gave a hint.

After some time it was deemed using DBus API calls directly was a
better way to go (since pkcheck calls them anyway). So, commit id
'1b854c76' (more or less) copied the code from remoteDispatchAuthPolkit
and adjusted it. Then commit id 'c7542573' adjusted the remote.c
code to call the new API (virPolkitCheckAuth). Finally, commit id
'308c0c5a' altered the code to call DBus APIs directly. In doing
so, it reverted the failing error message to the generic message
that would have been received from DBus anyway.

Rename to secretLoadAllConfigs and add the 'driver->configDir' as
a parameter.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

This new API will allocate the secret, assign the def pointer, and
insert the secret onto the passed list. Whether that's the temporary
list in loadSecrets which gets loaded into the driver list or driver
list during secretDefineXML.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Add a temporary helper to search for a specific secret by address
on the list and remove it if it's found. The following patch will
introduce a common allocation and listInsert helper. That means
error paths of the routines calling would need a way to remove the
secret off the list.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

This patch removes need for secretBase64Path and secretComputePath. Similar
to the configFile, create an entry for base64File, which will be generated
as the driver->configDir, the UUID value, plus the ".base" suffix. Rather
than generating on the fly, store this in the virSecretObj.

The buildup of the pathname done in loadSecrets where the failure to build
is ignored which is no different than the failure to generate the name
in secretLoadValue which would have been ignored in the failure path
after secretLoad.

This also removes the need for secretComputPath and secretBase64Path.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

This patch removes the need for secretXMLPath. Instead save 'path' during
loadSecret as 'configFile'. The secretXMLPath is nothing more than an
open coded virFileBuildPath.  All that code did was concantenate the
driver->configDir, the UUID of the secret, and the ".xml" suffix to form
the configFile name which we now will generate and save instead.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

The 'secretLoad' was essentially open coding virFileBuildPath.

Adjust the logic to have the caller build the path and pass it. The net
sum of ignoring the virFileBuildPath failure is the same as before where
the failure to virAsprintf the path would have been ignored anyway in
the secretLoad error path.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

This follows other drivers usage model.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Remove one letter variable.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Just renaming the variable in secretConnectListAllSecrets.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Remove the need for the local 'secret' in secretConnectListAllSecrets.
A subsequent patch will rename the ObjPtr entry to secret.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rename to virSecretObj - preparation for future patch, but also follows
similar code in other drivers.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Use the common API instead of essentially open coding same functionality.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than having it interspersed with other changes, do it once.

Remove a couple ^L, 1 argument per line for functions, less than 80 chars
per line, use of spacing between logical groups of code, use of one line
if statements when doing fetch followed by comparison, use direct return
when no cleanup to be done.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Use virCgroupAddTaskController in virCgroupAddTask so we have one
single point where we add tasks to cgroups.
Signed-off-by: NHenning Schild <henning.schild@siemens.com>

We honour the placement bitmaps when starting up, so there's no point in
having this check. Additionally the check was buggy since it checked
vm->def all the time even if the user requested to modify the persistent
definition which had different configuration.

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

Add Spice graphics gl attribute. qemu 2.6 should have -spice gl=on argument to
enable opengl rendering context (patches on the ML). This is necessary to
actually enable virgl rendering.

Add a qemuxml2argv test for virtio-gpu + spice with virgl.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Per-domain directories were introduced in order to be able to
completely separate security labels for each domain (commit
f1f68ca3).  However when the domain
name is long (let's say a ridiculous 110 characters), we cannot
connect to the monitor socket because on length of UNIX socket address
is limited.  In order to get around this, let's shorten it in similar
fashion and in order to avoid conflicts, throw in an ID there as well.
Also save that into the status XML and load the old status XMLs
properly (to clean up after older domains).  That way we can change it
in the future.

The shortening can be seen in qemuxml2argv tests, for example in the
hugepages-pages2 case.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

* docs/news.html.in libvirt.spec.in: update for release
* po/*.po*: regenerated

Found by inspection - after calling virStoragePoolObjAssignDef the
pool is part of the driver->pools.objs list and the failure path
for the virStoragePoolObjSaveDef will use virStoragePoolObjRemove
to remove the pool from the objs list which will unlock and free
the pool pointer (as pools->objs[i] during the loop). Since the call
doesn't clear the pool address from the callee, we need to set it
to NULL; otherwise, the virStoragePoolObjUnlock in the cleanup: code
will fail miserably.

While reviewing how storage driver used ObjListPtr's for reference
in some recent secret driver patches to use the same mechanism, I came
across an instance where the wrong API was called for error paths after
successfully allocating the storage pool pointer and inserting into
the driver pool list.

The path is after virStoragePoolObjAssignDef succeeds - the 'def' passed
in is assigned to pool->def (or newDef) so it shouldn't be the only thing
deleted. The pool is now part of driver->pools.objs, so it would need to
be removed (as happens in the storagePoolCreateXML error paths).

Rather than calling virStoragePoolDefFree to free the def which is now
assigned to the pool, call virStoragePoolObjRemove to ensure the pool
element is removed from the driver list and that anything stored in pool
is properly handled by virStoragePoolObjFree including the call to
virStoragePoolDefFree for the pool->{def|newDef} element.

Trivial documentation fix.
Signed-off-by: NRichard W.M. Jones <rjones@redhat.com>

Signed-off-by: NNitesh Konkar <nitkon12@linux.vnet.ibm.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Commit f1a89a8b allowed parsing configs from /etc/libvirt
without validating the emulator capabilities.

Check for the presence of a machine type in the qemu driver's
post parse function instead of crashing.

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

Check if we correctly parse the persistent config even with
the VIR_DOMAIN_DEF_PARSE_SKIP_OSTYPE_CHECKS flag.

Revert commit 55e6d8cd.

This fix for https://bugzilla.redhat.com/show_bug.cgi?id=1267256
unconditionally required a machine type for all machine types
even though qemu is the only emulator using them.

Revert it to fix persistent configs for drivers with no machine type:
https://www.redhat.com/archives/libvir-list/2016-February/msg01228.html

Allow testing XML parsing with different flags.

libxlMakeNic opens a virConnect object and takes a reference on a
virNetwork object, but doesn't drop the references on all error
paths. Rework the function to follow the standard libvirt pattern
of using a local 'ret' variable to hold the function return value,
performing all cleanup and returning 'ret' at a 'cleanup' label.

Generates a false positive for Coverity, but it turns out there's no need
to check ret == -1 since if VIR_APPEND_ELEMENT is successful, the local
vol pointer is cleared anyway.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Found by my Coverity checker - virCheckFlags call could return -1, but
not virCommandFree(destroy_cmd).
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

When parsing the barrier:limit values, use virStringSplitCount in order
to split the pair and make the approriate checks to get the data.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

The virHostdevIsVirtualFunction() was called exactly twice, and in
both cases the return value was saved to a temporary variable before
being checked. This would be okay if it improved readability, but in
this case is pretty pointless.

Get rid of the temporary variable and check the return value
directly; while at it, change the check from '<= 0' to '!= 1' to
align it with the way other similar *IsVirtualFunction() functions
are used thorough the code.

virNetDevIsVirtualFunction() returns 1 if the interface is a
virtual function, 0 if it isn't and -1 on error. This means that,
despite the name suggesting otherwise, using it as a predicate is
not correct.

Fix two callers that were doing so adding an explicit check on
the return value.

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

There's been a report on the upstream list [1] describing we
access /sys/devices/system/cpu/present directly on the host from
within our test suite. This may end up in unpredictable results
as no all linux systems are required to have that file. Mock
access to the file.

libvirt.git/tests $ ../run strace vircgrouptest
...
access("/sys/devices/system/cpu/present", F_OK) = 0
...
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>