Lock all the paths we want to relabel to mutually exclude other
libvirt daemons.
The only hitch here is that directories can't be locked.
Therefore, when relabeling a directory do not lock it (this
happens only when setting up some domain private paths anyway,
e.g. huge pages directory).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Firstly, the message that says we're setting uid:gid shouldn't be
called from virSecurityDACSetOwnershipInternal() because
virSecurityDACRestoreFileLabelInternal() is calling it too.
Secondly, there are places between us reporting label restore and
us actually doing it where we can quit. Don't say we're doing
something until we are actually about to do it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
So far the whole transaction handling is done
virSecurityDACSetOwnershipInternal(). This needs to change for
the sake of security label remembering and locking. Otherwise we
would be locking a path when only appending it to transaction
list and not when actually relabeling it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Two new APIs are added so that security driver can lock and
unlock paths it wishes to touch. These APIs are not for other
drivers to call but security drivers (DAC and SELinux). That is
the reason these APIs are not exposed through our
libvirt_private.syms file.
Three interesting things happen in this commit. The first is the
global @lockManagerMutex. Unfortunately, this has to exist so that
there is only one thread talking to virtlockd at a time. If there
were more threads and one of them closed the connection
prematurely, it would cause virtlockd killing libvirtd. Instead
of complicated code that would handle that, let's have a mutex
and keep the code simple.
The second interesting thing is keeping connection open between
lock and unlock API calls. This is achieved by duplicating client
FD and keeping it open until unlock is called. This trick is used
by regular disk content locking code when the FD is leaked to
qemu.
Finally, the third thing is polling implemented at client side.
Since virtlockd has only one thread that handles locking
requests, all it can do is either acquire lock or error out.
Therefore, the polling has to be implemented in client. The
polling is capped at 60 second timeout, which should be plenty
since the metadata lock is held only for a fraction of a second.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Now that we know what metadata lock manager user wishes to use we
can load it when initializing security driver. This is achieved
by adding new argument to virSecurityManagerNewDriver() and
subsequently to all functions that end up calling it.
The cfg.mk change is needed in order to allow lock_manager.h
inclusion in security driver without 'syntax-check' complaining.
This is safe thing to do as locking APIs will always exist (it's
only backend implementation that changes). However, instead of
allowing the include for all other drivers (like cpu, network,
and so on) allow it only for security driver. This will still
trigger the error if including from other drivers.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This config option allows users to set and enable lock manager
for domain metadata. The lock manager is going to be used by
security drivers to serialize each other when changing a file
ownership or changing the SELinux label. The only supported lock
manager is 'lockd' for now.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
In some cases we might want to not load the lock driver config.
Alter virLockManagerPluginNew() and the lock drivers to cope with
this fact.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Soon there will be a virtlockd client that wants to either lock
all the resources or none (in order to avoid virtlockd killing
the client on connection close). Because on the RPC layer we can
only acquire one resource at a time, we have to perform a
rollback once we hit a resource that can't be acquired.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This is a new type of object that lock drivers can handle.
Currently, it is supported by lockd driver only.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The fact whether domain has or doesn't have RW disks is specific
to VIR_LOCK_MANAGER_OBJECT_TYPE_DOMAIN and therefore should
reside in union specific to it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
We will want virtlockd to lock files on behalf of libvirtd and
not qemu process, because it is libvirtd that needs an exclusive
access not qemu. This requires new lock context.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This flag causes virtlockd to use different offset when locking
the file.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
So far the virLockSpaceAcquireResource() locks the first byte in
the underlying file. But caller might want to lock other range.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The file being present doesn't necessarily mean anything these
days, as it's created independently of whether the kvm module
has been loaded[1]; moreover, we're already gathering all the
information we need through QMP, so poking the filesystem at
all is entirely unnecessary.
[1] https://github.com/systemd/systemd/commit/d35d6249d5a7ed3228
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
This capability is documented as having one meaning (whether
KVM is enabled by default) but is actually assigned two other
meanings over its life: whether the query-kvm QMP command is
available at first, and later on whether KVM is usable / was
used during probing.
Since the query-kvm QMP command was available in 1.5.0, we
can avoid probing for it; additionally, we can simplify the
logic by setting the flag when it applies instead of initially
setting it and then clearing it when it doesn't.
The flag's description is also updated to reflect reality.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
A side effect of recent changes is that we would always try
to regenerate the capabilities cache for non-native QEMU
binaries based on /dev/kvm availability, which is of course
complete nonsense. Make sure that doesn't happen.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
It was already available in 1.5.0.
Moreover, we're not even formatting it on the QEMU command
line, ever: we just use it as part of some logic that decides
whether KVM support should be advertised, and as it turns out
that logic is actually buggy and dropping this capability
fixes it.
https://bugzilla.redhat.com/show_bug.cgi?id=1628469
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Now that committing transactions using pid == -1 means that we're
not fork()-ing to run the transaction in a specific namespace, we
can utilize the transaction processing semantics in order to
start, run a or multiple commands, and then commit the
transaction without being concerned with other interactions or
transactions interrupting the processing. This will eventually
allow us to have a single place where all the paths can be
locked, followed by relabeling and unlocking again.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
It will be desirable to run transactions more often than we
currently do. Even if the domain we're relabeling the paths for
does not run in a namespace. If that's the case, there is no need
to fork() as we are already running in the right namespace. To
differentiate whether transaction code should fork() or not the
@pid argument now accepts -1 (which means do not fork).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
In the future, the transactions are not going to be optional and
they will be run regardless of domain using namespace to collect
list of paths to be relabeled.
To make sure there won't be an API that goes behind transaction
code back update the comment that serves as decision manual
whether an API must be fully implemented or plain #define is
sufficient.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Even though the current use of the functions does not require full
implementation with transactions (none of the callers passes a path
somewhere under /dev), it doesn't hurt either. Moreover, in
future patches the paradigm is going to shift so that any API
that touches a file is required to use transactions.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Even though the current use of the function does not require full
implementation with transactions (none of the callers pass a path
somewhere under /dev), it doesn't hurt either. Moreover, in
future patches the paradigm is going to shift so that any API
that touches a file is required to use transactions.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Functions that deal with virPCIDeviceAddress exclusively
belong to util/virpci.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently the libxl driver claims support for Xen >= 4.4, but
Xen 4.4 and 4.5 are no longer supported upstream. Let's increase
the minimum supported Xen version to 4.6 and change the defined
LIBXL_API_VERSION to 0x040500, which is the API version defined
when Xen 4.6 was released.
Since Xen 4.6 contains a pkgconfig file, drop the now unused code
that falls back to using LIBVIRT_CHECK_LIB in the absence of
pkgconfig file. In addition, bumping the LIBXL_API_VERSION
required adjusting the calls to libxl_set_vcpuaffinity to account
for the extra parameter in the 0x040500 version of the API.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
commit b00c9c39 removed the label end_of_netlink_messages and 'return
table' statement, It causes the function virArpTableGet doesn't return
a proper virArpTable pointer.
How to reproduce:
# virsh domiflist sles12sp3
Interface Type Source Model MAC
-------------------------------------------------------
vnet0 network default virtio 52:54:00💿02:e6
# virsh domifaddr sles12sp3 --source arp
error: Failed to query for interfaces addresses
error: An error occurred, but the cause is unknown
It seems that the "if (nh->nlmsg_type == NLMSG_DONE)" statement won't be
meted. So this patch adds 'return table' when the iterations of nlmsghdr
for loop is over.
Signed-off-by: Lin Ma <lma@suse.com>
Reviewed-by: Chen Hanxiao <chenhanxiao@gmail.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
It is not a problem at all if the `tss` user/group does not exist, the code
fallbacks to the `root` user/group. However we report a warning for no reason
on every start-up. Fix this by checking if the user/group actually exists.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Instead of duplicating the code from virGet{User,Group}IDByName(), which are
static anyway, extend those functions to accept NULL pointers for the result and
a boolean for controlling the error reporting.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Otherwise after libvirtd restart we come back to issues fixed by
introducing this flag in [1].
[1] 61a0026a : qemu: Fix xml dump of autogenerated websocket
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
After removing the host CPU model re-computation,
this function is no longer necessary.
This reverts commits:
commit d0498881a0
virQEMUCapsFreeHostCPUModel: Don't always free host cpuData
commit 5276ec712a
testUpdateQEMUCaps: Don't leak host cpuData
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Commit 82327038 moved a couple of checks out of the XML parser
into the domain validation; however, those checks seem to be more
useful as hypervisor specific checks rather than the more general
domain conf checks (nothing in the docs indicate a specific error).
Fortunately only QEMU was processing the memoryBacking, thus
add the changes to qemuDomainDefValidateMemory and change the
code a bit to make usage of the similar deref to def->mem and
the mem->nhugepages filter.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
virDomainDefCollectBootOrder() is called for every item on the list
for each type of device. One of the checks it makes is to gather the
order attributes from the <boot> element of all devices, and assure
that no two devices have been given the same order.
Since (internally to libvirt, *not* in the domain XML) an <interface
type='hostdev'> is on both the list of hostdev devices and the list of
network devices, it will be counted twice, and the code that checks
for multiple devices with the same boot order will give a false
positive.
To remedy this, we make sure to return early for hostdev devices that
have a parent.type != NONE.
This was introduced in commit 5b75a4, which was first in libvirt-4.4.0.
Resolves: https://bugzilla.redhat.com/1601318
Signed-off-by: Laine Stump <laine@laine.org>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We require QEMU 1.5.0 these days, so checking for versions
older than that is pointless.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The capability was introduced in QEMU 1.5.0, which is our
minimum supported QEMU version these days.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The capability was introduced in QEMU 1.3.1 and we require
QEMU 1.5.0 these days.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1613737
When processing the inputvol for encryption, we need to handle
the case where the inputvol is encrypted. This then allows for
the encrypted inputvol to be used either for an output encrypted
volume or an output volume of some XML provided type.
Add tests to show the various conversion options when either input
or output is encrypted. This includes when both are encrypted.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
Commit 39cef12a9 altered/fixed the inputvol processing to create
a multistep process when using an inputvol to create an encrypted
output volume; however, it unnecessarily assumed/restricted the
inputvol to be of 'raw' format only.
Modify the processing code to allow the inputvol format to be checked
and used in order to create the encrypted volume.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
There's really no need for it to be there since it's only ever
used inside virStorageBackendCreateQemuImgCmdFromVol
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
In some cases we are checking if the mount namespace is enabled
at two places: one is at the beginning of exported function (e.g.
qemuDomainNamespaceSetupDisk()) and the other is at the beginning
of qemuDomainNamespaceMknodPaths() which is called from the
former function anyway. Then we have some other functions which
rely on the later check solely.
In order to compensate for possibly needless function call,
qemuDomainNamespaceMknodPaths() returns early if @npaths is zero.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This patch simplifies virNetDevBridgeCreate and virNetDevMacVLanCreate
functions by making use of the virNetlinkNewLink helper.
Signed-off-by: Shi Lei <shi_lei@massclouds.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This patch adds wrapper macros around nla_nest_[start|end] and nla_put,
thus getting rid of some redundancy and making virNetlinkNewLink more
readable.
Signed-off-by: Shi Lei <shi_lei@massclouds.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
This patch introduces virNetlinkNewLink helper which wraps the common
libnl/netlink code to create a new link.
Signed-off-by: Shi Lei <shi_lei@massclouds.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
