Since virDomainFree will call virObjectUnref anyway, let's just use that
directly so as to avoid the possibility that we inadvertently clear out
a pending error message when using the public API.
As qemu is now able to notify us about change of the channel state used
for communication with the guest agent we now can more precisely track
the state of the guest agent.
To allow notifying management apps this patch implements a new event
that will be triggered on changes of the guest agent state.
We weren't ever using the value for anything other than being non-zero.
* src/util/viraudit.h (virAuditLog): Change signature.
* src/util/viraudit.c (virAuditLog): Update user.
* daemon/libvirtd.c (main): Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
It would be nice to also print a params pointer and number of params in
the debug message and the previous limit for number of params in the rpc
message was too large. The 2048 params will be enough for future events.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
A long time ago in a galaxy far, far away it has been decided
that libvirt will manage not only domains but host as well. And
with my latest work on qemu driver supporting huge pages, we miss
the cherry on top: an API to allocate huge pages on the run.
Currently users are forced to log into the host and adjust the
huge pages pool themselves. However, with this API the problem
is gone - they can both size up and size down the pool.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Convert the remote daemon auth check and the access control
code to use the common polkit API for checking auth.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
This new event will use typedParameters to expose what has been actually
updated and the reason is that we can in the future extend any tunable
values or add new tunable values. With typedParameters we don't have to
worry about creating some other events, we will just use this universal
event to inform user about updates.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Clean up all _virDomainMemoryStat.
Signed-off-by: James <james.wangyufei@huawei.com>
Signed-off-by: Wang Rui <moon.wangrui@huawei.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Coverity complains that the comparison:
if (nfds && nfds > ((int)!!sock_path + (int)!!sock_path_ro))
could mean 'sock_path' is NULL. Later in virNetSocketNewListenUNIX
there's a direct dereference of path in the error path:
if (path[0] != '@')
A bit of sleuthing proves that upon entry to daemonSetupNetworking
there is no way for 'sock_path' to be NULL since daemonUnixSocketPaths
will set up 'sock_file' (although it may not set up 'sock_file_ro')
in all 3 paths.
Adjusted code to add ATTRIBUTE_NONNULL(3) on incoming path parameter and
then fixup the comparison of nfds to be a comparison against 2 or 1
depending on whether sock_path_ro is NULL or not.
With eblake's help - adjust the checks for stdinfd/stdoutfd to ensure the
values are within the range we expect; otherwise the dup2()'s and subsequent
VIR_CLOSE() calls cause Coverity to believe there's a resource leak.
Signed-off-by: John Ferlan <jferlan@redhat.com>
In each of these cases, Coverity complains that the result count returned
on error paths would be -1 disregarding that the count and the corresponding
are "linked" together (it doesn't know that). Simple enough to check and
remove the warning
Since times when vbox moved to the daemon (due to some licensing
issue) the subdrivers that vbox implements were registered, but not
opened since our generic subdrivers took priority. I've tried to fix
this in 65b7d553f3 but it was not correct. Apparently moving
vbox driver registration upfront changes the default connection URI
which makes some users sad. So, this commit breaks vbox into pieces
and register vbox's network and storage drivers first, and vbox driver
then at the end. This way, the vbox driver is registered in the order
it always was, but its subdrivers are registered prior the generic
ones.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Let's fix this before we bake in a painful API. Since we know
that we have exactly one non-negative fd on success, we might
as well return the fd directly instead of forcing the user to
pass in a pointer. Furthermore, I found some memory and fd
leaks while reviewing the code - the idea is that on success,
libvirtd will have handed two fds in two different directions:
one to qemu, and one to the RPC client.
* include/libvirt/libvirt.h.in (virDomainOpenGraphicsFD): Drop
unneeded parameter.
* src/driver.h (virDrvDomainOpenGraphicsFD): Likewise.
* src/libvirt.c (virDomainOpenGraphicsFD): Adjust interface to
return fd directly.
* daemon/remote.c (remoteDispatchDomainOpenGraphicsFd): Adjust
semantics.
* src/qemu/qemu_driver.c (qemuDomainOpenGraphicsFD): Likewise,
and plug fd leak.
* src/remote/remote_driver.c (remoteDomainOpenGraphicsFD):
Likewise, and plug memory and fd leak.
Signed-off-by: Eric Blake <eblake@redhat.com>
Introduce by 63fbcc692.
When start libvirtd with commandline "/usr/sbin/libvirtd -d -l -v",
we expect verbose(info level) log if neither environment variable
nor config file about logging controls is set. But in fact we can't
get any info priority log in the default output file.
The log priority of default output is VIR_LOG_DEFAULT(VIR_LOG_WARN),
so the info log is filtered out.
To record info priority log we must parse option -v before setting the
default output.
After this patch, we get all verbose log in the default output file.
Signed-off-by: Zhou Yimin <zhouyimin@huawei.com>
There are some stateless drivers which implement subdrivers
(typically vbox and its own network and storage subdrivers). However,
as of ba5f3c7c8e the vbox driver lives in the daemon, not the
client library. This means, in order for vbox (or any stateless domain
driver) to use its subdrivers, it must register before the general
drivers. Later, when the virConnectOpen function goes through the
subdrivers, stateless drivers are searched first. If the connection
request is aiming at stateless driver, it will be opened. Otherwise
the generic subdriver is opened.
The other change done in this commit is moving interface module load a
bit earlier to match the ordering in case libvirt is built without
driver modules.
Reported-by: Taowei Luo <uaedante@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Libvirt is really chatty when the DEBUG log level is enabled. When a
host uses journald we'd enable debug logging to journald when only
specifying the debug log level. As journald may employ rate throttling
this would lock up the daemon until it's able to flush all debug
messages.
This patch changes the default log level to VIR_LOG_INFO when using the
default (unconfigured) log output to journald.
To still allow debug logging to journald the user now has to explicitly
specify journald as a log output with priority 1 in the "log_outputs"
configuration option. This patch also changes the config file template
to be explicit about this change and notify the user about the possible
consequence of debug logging into journald.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1121955
Instead of maintaining two very similar APIs, add the "@mac" parameter
to virNetworkGetDHCPLeases and kill virNetworkGetDHCPLeasesForMAC. Both
of those functions would return data the same way, so making @mac an
optional filter simplifies a lot of stuff.
Don't leak the temporary variables on success if NULL is returned
for that field.
Don't dereference NULL on failure to allocate some of the temporaries.
Introduced by commit 990c3b6
The aim of the API is to get information on number of free pages
on the system. The API behaves similar to the
virNodeGetCellsFreeMemory(). User passes starting NUMA cell, the
count of nodes that he's interested in, pages sizes (yes,
multiple sizes can be queried at once) and the counts are
returned in an array.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When the block job event was first added, it was for block pull,
where the active layer of the disk remains the same name. It was
also in a day where we only cared about local files, and so we
always had a canonical absolute file name. But two things have
changed since then: we now have network disks, where determining
a single absolute string does not really make sense; and we have
two-phase jobs (copy and active commit) where the name of the
active layer changes between the first event (ready, on the old
name) and second (complete, on the pivoted name).
Adam Litke reported that having an unstable string between events
makes life harder for clients. Furthermore, all of our API that
operate on a particular disk of a domain accept multiple strings:
not only the absolute name of the active layer, but also the
destination device name (such as 'vda'). As this latter name is
stable, even for network sources, it serves as a better string
to supply in block job events.
But backwards-compatibility demands that we should not change the
name handed to users unless they explicitly request it. Therefore,
this patch adds a new event, BLOCK_JOB_2 (alas, I couldn't think of
any nicer name - but at least Migrate2 and Migrate3 are precedent
for a number suffix). We must double up on emitting both old-style
and new-style events according to what clients have registered for
(see also how IOError and IOErrorReason emits double events, but
there the difference was a larger struct rather than changed
meaning of one of the struct members).
Unfortunately, adding a new event isn't something that can easily
be broken into pieces, so the commit is rather large.
* include/libvirt/libvirt.h.in (virDomainEventID): Add a new id
for VIR_DOMAIN_EVENT_ID_BLOCK_JOB_2.
(virConnectDomainEventBlockJobCallback): Document new semantics.
* src/conf/domain_event.c (_virDomainEventBlockJob): Rename field,
to ensure we catch all clients.
(virDomainEventBlockJobNew): Add parameter.
(virDomainEventBlockJobDispose)
(virDomainEventBlockJobNewFromObj)
(virDomainEventBlockJobNewFromDom)
(virDomainEventDispatchDefaultFunc): Adjust clients.
(virDomainEventBlockJob2NewFromObj)
(virDomainEventBlockJob2NewFromDom): New functions.
* src/conf/domain_event.h: Add new prototypes.
* src/libvirt_private.syms (domain_event.h): Export new functions.
* src/qemu/qemu_driver.c (qemuDomainBlockJobImpl): Generate two
different events.
* src/qemu/qemu_process.c (qemuProcessHandleBlockJob): Likewise.
* src/remote/remote_protocol.x
(remote_domain_event_block_job_2_msg): New struct.
(REMOTE_PROC_DOMAIN_EVENT_BLOCK_JOB_2): New RPC.
* src/remote/remote_driver.c
(remoteDomainBuildEventBlockJob2): New handler.
(remoteEvents): Register new event.
* daemon/remote.c (remoteRelayDomainEventBlockJob2): New handler.
(domainEventCallbacks): Register new event.
* tools/virsh-domain.c (vshEventCallbacks): Likewise.
(vshEventBlockJobPrint): Adjust client.
* src/remote_protocol-structs: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
These APIs allow users to get or set time in a domain, which may come
handy if the domain has been resumed just recently and NTP is not
configured or hasn't kicked in yet and the guest is running
something time critical. In addition, NTP may refuse to re-set the clock
if the skew is too big.
In addition, new ACL attribute is introduced 'set_time'.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Fixes leak introduced by e562e82f
==4937== 64 bytes in 1 blocks are definitely lost in loss record 270 of 405
==4937== at 0x4A06BE0: realloc (vg_replace_malloc.c:662)
==4937== by 0x6FA41C4: __vasprintf_chk (vasprintf_chk.c:90)
==4937== by 0x50C8D29: virVasprintfInternal (stdio2.h:199)
==4937== by 0x50C8E3A: virAsprintfInternal (virstring.c:362)
==4937== by 0x11D01A: main (libvirtd.c:1170)
Signed-off-by: Ján Tomko <jtomko@redhat.com>
These are the first async events in the qemu protocol, so this
patch looks rather big compared to most RPC additions. However,
a large majority of this patch is just mechanical copy-and-paste
from recently-added network events. It didn't help that this
is also the first virConnect rather than virDomain prefix
associated with a qemu-specific API.
* src/remote/qemu_protocol.x (qemu_*_domain_monitor_event_*): New
structs and RPC messages.
* src/rpc/gendispatch.pl: Adjust naming conventions.
* daemon/libvirtd.h (daemonClientPrivate): Track qemu events.
* daemon/remote.c (remoteClientFreeFunc): Likewise.
(remoteRelayDomainQemuMonitorEvent)
(qemuDispatchConnectDomainMonitorEventRegister)
(qemuDispatchConnectDomainMonitorEventDeregister): New functions.
* src/remote/remote_driver.c (qemuEvents): Handle qemu events.
(doRemoteOpen): Register for events.
(remoteNetworkBuildEventLifecycle)
(remoteConnectDomainQemuMonitorEventRegister)
(remoteConnectDomainQemuMonitorEventDeregister): New functions.
* src/qemu_protocol-structs: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
A earlier commit changed the global log buffer so that it only
records messages that are explicitly requested via the log
filters setting. This removes the performance burden, and
improves the signal/noise ratio for messages in the global
buffer. At the same time though, it is somewhat pointless, since
all the recorded log messages are already going to be sent to an
explicit log output like syslog, stderr or the journal. The
global log buffer is thus just duplicating this data on stderr
upon crash.
The log_buffer_size config parameter is left in the augeas
lens to prevent breakage for users on upgrade. It is however
completely ignored hereafter.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Any source file which calls the logging APIs now needs
to have a VIR_LOG_INIT("source.name") declaration at
the start of the file. This provides a static variable
of the virLogSource type.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The dtrace probe macros rely on the logging API. We can't make
the internal.h header include the virlog.h header though since
that'd be a circular include. Instead simply split the dtrace
probes into their own header file, since there's no compelling
reason for them to be in the main internal.h header.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=992980
This config tunable allows users to determine the maximum number of
accepted but yet not authenticated users.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The counter gets incremented on each unauthenticated client added to the
server and decremented whenever the client authenticates.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Our current pidfile acquire APis (virPidFileAcquire) simply return -1 upon
failure to acquire a lock. This patch adds a parameter 'bool waitForLock'
which instructs the APIs if we want to make it block and wait for the lock
or not.
When libvirtd is run from a build directory without being installed, it
should not depend on files from a libvirt package installed in the
system. Not only because there may not be any libvirt installed at all.
We already do a good job for plugins but cpu_map.xml was still loaded
from the system.
The Makefile.am change is necessary to make this all work from VPATH
builds since libvirtd has no idea where to find libvirt sources. It only
knows the path from which it was started, i.e, a builddir.
https://bugzilla.redhat.com/show_bug.cgi?id=1074327
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The future QEMU capabilities cache needs to be able to invalidate
itself if the libvirtd binary or any loadable modules are changed
on disk. Record the 'ctime' value for these binaries and provide
helper APIs to query it. This approach assumes that if libvirt.so
is changed, then libvirtd will also change, which should usually
be the case with libtool's wrapper scripts that cause libvirtd to
get re-linked
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Auditing all callers of virCommandRun and virCommandWait that
passed a non-NULL pointer for exit status turned up some
interesting observations. Many callers were merely passing
a pointer to avoid the overall command dying, but without
caring what the exit status was - but these callers would
be better off treating a child death by signal as an abnormal
exit. Other callers were actually acting on the status, but
not all of them remembered to filter by WIFEXITED and convert
with WEXITSTATUS; depending on the platform, this can result
in a status being reported as 256 times too big. And among
those that correctly parse the output, it gets rather verbose.
Finally, there were the callers that explicitly checked that
the status was 0, and gave their own message, but with fewer
details than what virCommand gives for free.
So the best idea is to move the complexity out of callers and
into virCommand - by default, we return the actual exit status
already cleaned through WEXITSTATUS and treat signals as a
failed command; but the few callers that care can ask for raw
status and act on it themselves.
* src/util/vircommand.h (virCommandRawStatus): New prototype.
* src/libvirt_private.syms (util/command.h): Export it.
* docs/internals/command.html.in: Document it.
* src/util/vircommand.c (virCommandRawStatus): New function.
(virCommandWait): Adjust semantics.
* tests/commandtest.c (test1): Test it.
* daemon/remote.c (remoteDispatchAuthPolkit): Adjust callers.
* src/access/viraccessdriverpolkit.c (virAccessDriverPolkitCheck):
Likewise.
* src/fdstream.c (virFDStreamCloseInt): Likewise.
* src/lxc/lxc_process.c (virLXCProcessStart): Likewise.
* src/qemu/qemu_command.c (qemuCreateInBridgePortWithHelper):
Likewise.
* src/xen/xen_driver.c (xenUnifiedXendProbe): Simplify.
* tests/reconnect.c (mymain): Likewise.
* tests/statstest.c (mymain): Likewise.
* src/bhyve/bhyve_process.c (virBhyveProcessStart)
(virBhyveProcessStop): Don't overwrite virCommand error.
* src/libvirt.c (virConnectAuthGainPolkit): Likewise.
* src/openvz/openvz_driver.c (openvzDomainGetBarrierLimit)
(openvzDomainSetBarrierLimit): Likewise.
* src/util/virebtables.c (virEbTablesOnceInit): Likewise.
* src/util/viriptables.c (virIpTablesOnceInit): Likewise.
* src/util/virnetdevveth.c (virNetDevVethCreate): Fix debug
message.
* src/qemu/qemu_capabilities.c (virQEMUCapsInitQMP): Add comment.
* src/storage/storage_backend_iscsi.c
(virStorageBackendISCSINodeUpdate): Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
Right now, a caller waiting for a child process either requires
the child to have status 0, or must use WIFEXITED() and friends
itself. But in many cases, we want the middle ground of treating
fatal signals as an error, and directly accessing the normal exit
value without having to use WEXITSTATUS(), in order to easily
detect an expected non-zero exit status. This adds the middle
ground to the low-level virProcessWait; the next patch will add
it to virCommand.
* src/util/virprocess.h (virProcessWait): Alter signature.
* src/util/virprocess.c (virProcessWait): Add parameter.
(virProcessRunInMountNamespace): Adjust caller.
* src/util/vircommand.c (virCommandWait): Likewise.
* src/util/virfile.c (virFileAccessibleAs): Likewise.
* src/lxc/lxc_container.c (lxcContainerHasReboot)
(lxcContainerAvailable): Likewise.
* daemon/libvirtd.c (daemonForkIntoBackground): Likewise.
* tools/virt-login-shell.c (main): Likewise.
* tools/virsh-domain.c (cmdLxcEnterNamespace): Likewise.
* tests/testutils.c (virtTestCaptureProgramOutput): Likewise.
* tests/commandtest.c (test23): Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
Systemd does not forget about the cases, where client service needs to
wait for daemon service to initialize and start accepting new clients.
Setting a dependency in client is not enough as systemd doesn't know
when the daemon has initialized itself and started accepting new
clients. However, it offers a mechanism to solve this. The daemon needs
to call a special systemd function by which the daemon tells "I'm ready
to accept new clients". This is exactly what we need with
libvirtd-guests (client) and libvirtd (daemon). So now, with this
change, libvirt-guests.service is invoked not any sooner than
libvirtd.service calls the systemd notify function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
At this point it has a limited functionality and is highly
experimental. Supported domain operations are:
* define
* start
* destroy
* dumpxml
* dominfo
It's only possible to have only one disk device and only one
network, which should be of type bridge.
Commit 57ddcc23 (v0.9.11) introduced the pmwakeup event, with
an optional 'reason' field reserved for possible future expansion.
But it failed to wire the field through RPC, so even if we do
add a reason in the future, we will be unable to get it back
to the user.
Worse, commit 7ba5defb (v1.0.0) repeated the same mistake with
the pmsuspend_disk event.
As long as we are adding new RPC calls, we might as well fix
the events to actually match the signature so that we don't have
to add yet another RPC in the future if we do decide to start
using the reason field.
* src/remote/remote_protocol.x
(remote_domain_event_callback_pmwakeup_msg)
(remote_domain_event_callback_pmsuspend_msg)
(remote_domain_event_callback_pmsuspend_disk_msg): Add reason
field.
* daemon/remote.c (remoteRelayDomainEventPMWakeup)
(remoteRelayDomainEventPMSuspend)
(remoteRelayDomainEventPMSuspendDisk): Pass reason to client.
* src/conf/domain_event.h (virDomainEventPMWakeupNewFromDom)
(virDomainEventPMSuspendNewFromDom)
(virDomainEventPMSuspendDiskNewFromDom): Require additional
parameter.
* src/conf/domain_event.c (virDomainEventPMClass): New class.
(virDomainEventPMDispose): New function.
(virDomainEventPMWakeupNew*, virDomainEventPMSuspendNew*)
(virDomainEventPMSuspendDiskNew*)
(virDomainEventDispatchDefaultFunc): Use new class.
* src/remote/remote_driver.c (remoteDomainBuildEvent*PM*): Pass
reason through.
* src/remote_protocol-structs: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
Following the patterns established by lifecycle events, this
creates all the new RPC calls needed to pass callback IDs
for every domain event, and changes the limits in client and
server codes to use modern style when possible.
I've tested all combinations: both 'old client and new server'
and 'new client and old server' continue to work with the old
RPCs, and 'new client and new server' benefit from server-side
filtering with the new RPCs.
* src/remote/remote_protocol.x (REMOTE_PROC_DOMAIN_EVENT_*): Add
REMOTE_PROC_DOMAIN_EVENT_CALLBACK_* counterparts.
* daemon/remote.c (remoteRelayDomainEvent*): Send callbackID via
newer RPC when used with new-style registration.
(remoteDispatchConnectDomainEventCallbackRegisterAny): Extend to
cover all domain events.
* src/remote/remote_driver.c (remoteDomainBuildEvent*): Add new
Callback and Helper functions.
(remoteEvents): Match order of RPC numbers, register new handlers.
(remoteConnectDomainEventRegisterAny)
(remoteConnectDomainEventDeregisterAny): Extend to cover all
domain events.
* src/remote_protocol-structs: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
This patch adds some new RPC call numbers, but for ease of review,
they sit idle until a later patch adds the client counterpart to
drive the new RPCs. Also for ease of review, I limited this patch
to just the lifecycle event; although converting the remaining
15 domain events will be quite mechanical. On the server side,
we have to have a function per RPC call, largely with duplicated
bodies (the key difference being that we store in our callback
opaque pointer whether events should be fired with old or new
style); meanwhile, a single function can drive multiple RPC
messages. With a strategic choice of XDR struct layout, we can
make the event generation code for both styles fairly compact.
I debated about adding a tri-state witness variable per
connection (values 'unknown', 'legacy', 'modern'). It would start
as 'unknown', move to 'legacy' if any RPC call is made to a legacy
event call, and move to 'modern' if the feature probe is made;
then the event code could issue an error if the witness state is
incorrect (a legacy RPC call while in 'modern', a modern RPC call
while in 'unknown' or 'legacy', and a feature probe while in
'legacy' or 'modern'). But while it might prevent odd behavior
caused by protocol fuzzing, I don't see that it would prevent
any security holes, so I considered it bloat.
Note that sticking @acl markers on the new RPCs generates unused
functions in access/viraccessapicheck.c, because there is no new
API call that needs to use the new checks; however, having a
consistent .x file is worth the dead code.
* src/libvirt_internal.h (VIR_DRV_FEATURE_REMOTE_EVENT_CALLBACK):
New feature.
* src/remote/remote_protocol.x
(REMOTE_PROC_CONNECT_DOMAIN_EVENT_CALLBACK_REGISTER_ANY)
(REMOTE_PROC_CONNECT_DOMAIN_EVENT_CALLBACK_DEREGISTER_ANY)
(REMOTE_PROC_DOMAIN_EVENT_CALLBACK_LIFECYCLE): New RPCs.
* daemon/remote.c (daemonClientCallback): Add field.
(remoteDispatchConnectDomainEventCallbackRegisterAny)
(remoteDispatchConnectDomainEventCallbackDeregisterAny): New
functions.
(remoteDispatchConnectDomainEventRegisterAny)
(remoteDispatchConnectDomainEventDeregisterAny): Mark legacy use.
(remoteRelayDomainEventLifecycle): Change message based on legacy
or new use.
(remoteDispatchConnectSupportsFeature): Advertise new feature.
* src/remote_protocol-structs: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
This patch continues the earlier conversion made for network
events, with a goal of introducing server-side event filtering
in a later patch. Actual behavior is unchanged without
further RPC changes.
* daemon/libvirtd.h (daemonClientPrivate): Alter the tracking of
domain events.
* daemon/remote.c (remoteClientInitHook, remoteClientFreeFunc)
(remoteRelayDomainEvent*)
(remoteDispatchConnectDomainEventRegister)
(remoteDispatchConnectDomainEventRegisterAny): Track domain
callbacks dynamically.
Noticed a misuse of 'to' while testing my event regression under
polkit ACLs, and decided to review the entire conf files for
other legibility bugs.
* daemon/libvirtd.conf: Use correct grammar.
* src/qemu/qemu.conf: Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1058839
Commit f9f56340 for CVE-2014-0028 almost had the right idea - we
need to check the ACL rules to filter which events to send. But
it overlooked one thing: the event dispatch queue is running in
the main loop thread, and therefore does not normally have a
current virIdentityPtr. But filter checks can be based on current
identity, so when libvirtd.conf contains access_drivers=["polkit"],
we ended up rejecting access for EVERY event due to failure to
look up the current identity, even if it should have been allowed.
Furthermore, even for events that are triggered by API calls, it
is important to remember that the point of events is that they can
be copied across multiple connections, which may have separate
identities and permissions. So even if events were dispatched
from a context where we have an identity, we must change to the
correct identity of the connection that will be receiving the
event, rather than basing a decision on the context that triggered
the event, when deciding whether to filter an event to a
particular connection.
If there were an easy way to get from virConnectPtr to the
appropriate virIdentityPtr, then object_event.c could adjust the
identity prior to checking whether to dispatch an event. But
setting up that back-reference is a bit invasive. Instead, it
is easier to delay the filtering check until lower down the
stack, at the point where we have direct access to the RPC
client object that owns an identity. As such, this patch ends
up reverting a large portion of the framework of commit f9f56340.
We also have to teach 'make check' to special-case the fact that
the event registration filtering is done at the point of dispatch,
rather than the point of registration. Note that even though we
don't actually use virConnectDomainEventRegisterCheckACL (because
the RegisterAny variant is sufficient), we still generate the
function for the purposes of documenting that the filtering
takes place.
Also note that I did not entirely delete the notion of a filter
from object_event.c; I still plan on using that for my upcoming
patch series for qemu monitor events in libvirt-qemu.so. In
other words, while this patch changes ACL filtering to live in
remote.c and therefore we have no current client of the filtering
in object_event.c, the notion of filtering in object_event.c is
still useful down the road.
* src/check-aclrules.pl: Exempt event registration from having to
pass checkACL filter down call stack.
* daemon/remote.c (remoteRelayDomainEventCheckACL)
(remoteRelayNetworkEventCheckACL): New functions.
(remoteRelay*Event*): Use new functions.
* src/conf/domain_event.h (virDomainEventStateRegister)
(virDomainEventStateRegisterID): Drop unused parameter.
* src/conf/network_event.h (virNetworkEventStateRegisterID):
Likewise.
* src/conf/domain_event.c (virDomainEventFilter): Delete unused
function.
* src/conf/network_event.c (virNetworkEventFilter): Likewise.
* src/libxl/libxl_driver.c: Adjust caller.
* src/lxc/lxc_driver.c: Likewise.
* src/network/bridge_driver.c: Likewise.
* src/qemu/qemu_driver.c: Likewise.
* src/remote/remote_driver.c: Likewise.
* src/test/test_driver.c: Likewise.
* src/uml/uml_driver.c: Likewise.
* src/vbox/vbox_tmpl.c: Likewise.
* src/xen/xen_driver.c: Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
I noticed this problem when adding systemd support to netcf, because I
setup the configure.ac to automatically prefer using systemd over
initscripts when possible - although I had copied the
install-data-local target from the example of libvirt's
"libvirt-guests" service more or less verbatim, "make distcheck" would
fail because it was trying to install the service file directly into
/lib/systemd/system rather than into
/home/user/some/unimportant/name/lib/systemd/system.
This is caused by the install/uninstall rules for the systemd unit
files relying on $(DESTDIR) pointing the installed files to the right
place, but in reality $(DESTDIR) is empty during this part of make
distcheck - it instead sets $(prefix) with the toplevel directory used
for its test build/install/uninstall cycle.
(This problem hasn't been seen when running "make distcheck" in
libvirt because libvirt will never build/install systemd support
unless explicitly told to do so on the configure commandline, and
"make distcheck" doesn't put the "--with-initscript=..." option on the
configure commandline.)
I verified that the same problem does exist in libvirt by modifying
libvirt's configure.ac to set:
init_systemd=yes
with_init_script=systemd+redhat
This forces a build/install of the systemd unit files during
distcheck, which yields an error like this:
/usr/bin/install -c -m 644 virtlockd.service \
/lib/systemd/system/
libtool: install: warning: relinking `libvirt-qemu.la'
/usr/bin/install: cannot remove '/lib/systemd/system/virtlockd.service': Permission denied
make[4]: *** [install-systemd] Error 1
After adding $(prefix) to all the definitions of SYSTEMD_UNIT_DIR,
make distcheck now completes successfully with the modified
configure.ac, and the above lines change to something like this:
/usr/bin/install -c -m 644 virtlockd.service \
/home/laine/devel/libvirt/libvirt-1.2.1/_inst/lib/systemd/system/
We haven't had a release with network events yet, so we are free
to fix the RPC so that it actually does what we want. Doing
client-side filtering of per-network events is inefficient if a
connection is only interested in events on a single network out
of hundreds available on the server. But to do server-side
per-network filtering, the server needs to know which network
to filter on - so we need to pass an optional network over on
registration. Furthermore, it is possible to have a client with
both a global and per-network filter; in the existing code, the
server sends only one event and the client replicates to both
callbacks. But with server-side filtering, the server will send
the event twice, so we need a way for the client to know which
callbackID is sending an event, to ensure that the client can
filter out events from a registration that does not match the
callbackID from the server. Likewise, the existing style of
deregistering by eventID alone is fine; but in the new style,
we have to remember which callbackID to delete.
This patch fixes the RPC wire definition to contain all the
needed pieces of information, and hooks into the server and
client side improvements of the previous patches, in order to
switch over to full server-side filtering of network events.
Also, since we fixed this in time, all released versions of
libvirtd that support network events also support per-network
filtering, so we can hard-code that assumption into
network_event.c.
Converting domain events to server-side filtering will require
the introduction of new RPC numbers, as well as a server
feature bit that the client can use to tell whether to use
old-style (server only supports global events) or new-style
(server supports filtered events), so that is deferred to a
later set of patches.
* src/conf/network_event.c (virNetworkEventStateRegisterClient):
Assume server-side filtering.
* src/remote/remote_protocol.x
(remote_connect_network_event_register_any_args): Add network
argument.
(remote_connect_network_event_register_any_ret): Return callbackID
instead of count.
(remote_connect_network_event_deregister_any_args): Pass
callbackID instead of eventID.
(remote_connect_network_event_deregister_any_ret): Drop unused
type.
(remote_network_event_lifecycle_msg): Add callbackID.
* daemon/remote.c
(remoteDispatchConnectNetworkEventDeregisterAny): Drop unused arg,
and deal with callbackID from client.
(remoteRelayNetworkEventLifecycle): Pass callbackID.
(remoteDispatchConnectNetworkEventRegisterAny): Likewise, and
recognize non-NULL network.
* src/remote/remote_driver.c
(remoteConnectNetworkEventRegisterAny): Pass network, and track
server side id.
(remoteConnectNetworkEventDeregisterAny): Deregister by callback id.
(remoteNetworkBuildEventLifecycle): Pass remote id to event queue.
* src/remote_protocol-structs: Regenerate.
Signed-off-by: Eric Blake <eblake@redhat.com>
Right now, the daemon side of RPC events is hard-coded to at most
one callback per eventID. But when there are hundreds of domains
or networks coupled and multiple conections, then sending every
event to every connection that wants an event, even for the
connections that only care about events for a particular object,
is inefficient. In order to track more than one callback in the
server, we need to store callbacks by more than just their
eventID. This patch rearranges the daemon side to store network
callbacks in a dynamic array, which can eventually be used for
multiple callbacks of the same eventID, although actual behavior
is unchanged without further patches to the RPC protocol. For
ease of review, domain events are saved for a later patch, as
they touch more code.
While at it, fix a bug where a malicious client could send a
negative eventID to cause network event registration to access
outside of array bounds (thankfully not a CVE, since domain
events were already doing the bounds check, and since network
events have not been released).
* daemon/libvirtd.h (daemonClientPrivate): Alter the tracking of
network events.
* daemon/remote.c (daemonClientEventCallback): New struct.
(remoteEventCallbackFree): New function.
(remoteClientInitHook, remoteRelayNetworkEventLifecycle)
(remoteClientFreeFunc)
(remoteDispatchConnectNetworkEventRegisterAny): Track network
callbacks differently.
(remoteDispatchConnectNetworkEventDeregisterAny): Enforce bounds.
Signed-off-by: Eric Blake <eblake@redhat.com>
- Use SIGUSR1, not SIGHUP, on reload. At present, virtlockd only
responds to the former.
- Fix PID file for virtlockd.
- Do not start virtlockd in any runlevels by default. It needs to be
explicitly selected in libvirt's qemu.conf anyway, so there is no
need to have it running on all systems regardless.
- Fix chkconfig priorities to ensure virtlockd is started before
libvirtd is started, and stopped after libvirtd is stopped.
- Add "Should-Start: virtlockd" to the libvirtd initscript's LSB header,
for the same reason.
- Add "Default-Stop" to both libvirtd and virtlockd initscripts. LSB
does not guarantee that this defaults to the inverse of
"Default-Start".
Signed-off-by: Michael Chapman <mike@very.puzzling.org>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1033061
Currently, initialization of drivers is done in a separate thread. This
is done for several reasons: a driver that is initialized may require
running event loop, it may take ages to initialize driver (e.g. due to
autostarting domains). While the thread is spawn and run, the main()
continues its execution. However, if something goes bad, or the event
loop is just exited (e.g. due to a --timeout or SIGINT) we try to
cleanup all the drivers. So we have two threads running Initialize() and
Cleanup() concurrently. This may result in accessing stale pointers -
e.g. netcf driver will free() itself in stateCleanup callback, while the
init thread may come, open a dummy connection in order to autostart some
domains and voilà: do_open() iterates over interface drivers and
accesses stale netcf driver.
The fix consists in not running stateCleanup if the init thread is still
running.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Unconditional use of getenv is not secure in setuid env.
While not all libvirt code runs in a setuid env (since
much of it only exists inside libvirtd) this is not always
clear to developers. So make all the code paranoid, even
if it only ever runs inside libvirtd.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The libvirt.so library has far too many library deps to allow
linking against it from setuid programs. Those libraries can
do stuff in __attribute__((constructor) functions which is
not setuid safe.
The virt-login-shell needs to link directly against individual
files that it uses, with all library deps turned off except
for libxml2 and libselinux.
Create a libvirt-setuid-rpc-client.la library which is linked
to by virt-login-shell. A config-post.h file allows this library
to disable all external deps except libselinux and libxml2.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The libvirtd server pushes data out to clients. It does not
know what protocol version the client might have, so must be
conservative and use the old payload limits. ie send no more
than 256kb of data per packet.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
When a client disconnects from libvirtd, all event callbacks
must be removed. This involves running the public API
virConnectDomainEventDeregisterAny
This code does not run in normal API dispatch context, so no
identity was set. The result was that the access control drivers
denied the attempt to deregister callbacks. The callbacks thus
continued to trigger after the client was free'd causing fairly
predictable use of free memory & a crash.
This can be triggered by any client with readonly access when
the ACL drivers are active.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Caused by commit 012c25e8 splitting out a convenience library.
CC libvirtd_conf_la-libvirtd-config.lo
In file included from ../src/rpc/virnetmessage.h:24:0,
from ../src/rpc/virnetserverprogram.h:27,
from ../src/rpc/virnetserver.h:32,
from libvirtd-config.c:31:
../src/rpc/virnetprotocol.h:9:21: fatal error: rpc/rpc.h: No such file
or directory
* daemon/Makefile.am (libvirtd_conf_la_CFLAGS): Add XDR_CFLAGS.
Signed-off-by: Eric Blake <eblake@redhat.com>
A previous patch used existing #define for the various files in /etc/pki
instead of hardcoding them in the help output. However I missed that
remote_driver.h contains #define for more paths that are present
in the daemon help output.
This commit uses the existing constants for the path to the
configuration file and to the libvirt sockets.
The 'stats' variable was not initialized to NULL, so if some
early validation of the RPC call fails, it is possible to jump
to the 'cleanup' label and VIR_FREE an uninitialized pointer.
This is a security flaw, since the API can be called from a
readonly connection which can trigger the validation checks.
This was introduced in release v0.9.1 onwards by
commit 158ba8730e
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Wed Apr 13 16:21:35 2011 +0100
Merge all returns paths from dispatcher into single path
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
With the existing pkcheck (pid, start time) tuple for identifying
the process, there is a race condition, where a process can make
a libvirt RPC call and in another thread exec a setuid application,
causing it to change to effective UID 0. This in turn causes polkit
to do its permission check based on the wrong UID.
To address this, libvirt must get the UID the caller had at time
of connect() (from SO_PEERCRED) and pass a (pid, start time, uid)
triple to the pkcheck program.
This fix requires that libvirt is re-built against a version of
polkit that has the fix for its CVE-2013-4288, so that libvirt
can see 'pkg-config --variable pkcheck_supports_uid polkit-gobject-1'
Signed-off-by: Colin Walters <walters@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
There are constants for these paths in remote_driver.h so we can
use these rather than duplicating them in the help output.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
The help message indicates that the CA certificate is
$sysconfdir/pki/CA/caert.pem while the actual path is
$sysconfdir/pki/CA/cacert.pem
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
If we use subdir-objects with automake, any reference to a
cross-directory .c file will result in automake creating
rules that track dependency in the cross directory. But this
presents a problem during 'make distclean' - if the cross
directory is cleaned up first, then the daemon directory will
be left with dangling references to .Po dependency files that
no longer exist.
Meanwhile, referring to the cross-directory .c file means
that we are compiling the file twice - once in src, and once
in daemon. Better is to compile just once in src into a
convenience library, and then use that library from daemon.
The tests directory had a similar situation of a cross-directory
.c file; to solve that, we actually need a convenience library.
* daemon/Makefile.am (DAEMON_SOURCES): Drop .c files...
(libvirtd_LDADD): ...and instead use library.
(libvirtd_conf_la_SOURCES): Declare a new convenience library.
(libvirtd_LDFLAGS): Drop duplicate flag.
* tests/Makefile.am (libvirtdconftest_SOURCES): Drop .c file...
(libvirtdconftest_LDADD): ..and instead use library.
Signed-off-by: Eric Blake <eblake@redhat.com>
Trying to enable automake's subdir-objects option resulted in
the creation of literal directories such as src/$(srcdir)/remote/.
I traced this to the fact that we had used a literal $(srcdir)
in a location that later fed an automake *_SOURCES variable.
This has also been reported as an automake bug:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13928
but it's better to fix our code than to wait for an automake fix.
Some things to remember that affect VPATH builds, and where an
in-tree build is blissfully unaware of the issues: if a VPATH
build fails to find a file that was used as a prereq of any
other target, then the rule for that file will expand $@ to
prefer the current build dir (bad because a VPATH build on a
fresh checkout will then stick $@ in the current directory
instead of the desired srcdir); conversely, if a VPATH build
finds the file in srcdir but decides it needs to be rebuilt,
then the rule for that file will expand $@ to include the
directory where it was found out-of-date (bad for an explicit
listing of $(srcdir)/$@ because an incremental VPATH build will
then expand srcdir twice). As we want these files to go into
srcdir unconditionally, we have to massage or avoid $@ for any
recipe that involves one of these files.
Therefore, this patch removes all uses of $(srcdir) from any
generated file name that later feeds a *_SOURCES variable, and
then rewrites all the recipes to generate those files to
hard-code their creation into srcdir without the use of $@.
* src/Makefile.am (REMOTE_DRIVER_GENERATED): Drop $(srcdir); VPATH
builds know how to find the files, and automake subdir-objects
fails with it in place.
(LXC_MONITOR_PROTOCOL_GENERATED, (LXC_MONITOR_GENERATED)
(ACCESS_DRIVER_GENERATED, LOCK_PROTOCOL_GENERATED): Likewise.
(*_client_bodies.h): Hard-code rules to write into srcdir, as
VPATH tries to build $@ locally if missing.
(util/virkeymaps.h): Likewise.
(lxc/lxc_monitor_dispatch.h): Likewise.
(access/viraccessapi*): Likewise.
(locking/lock_daemon_dispatch_stubs.h): Likewise.
* daemon/Makeflie.am (DAEMON_GENERATED, remote_dispatch.h):
Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
fixup DAEMON_GENERATED
Automake has builtin support to prevent botched conditional nesting,
but only if you use:
if FOO
else !FOO
endif !FOO
An example error message when using the wrong name:
daemon/Makefile.am:378: error: else reminder (LIBVIRT_INIT_SCRIPT_SYSTEMD_TRUE) incompatible with current conditional: LIBVIRT_INIT_SCRIPT_SYSTEMD_FALSE
daemon/Makefile.am:381: error: endif reminder (LIBVIRT_INIT_SCRIPT_SYSTEMD_TRUE) incompatible with current conditional: LIBVIRT_INIT_SCRIPT_SYSTEMD_FALSE
As our makefiles tend to have quite a bit of nested conditionals,
it's better to take advantage of the benefits of the build system
double-checking that our conditionals are well-nested, but that
requires a syntax check to enforce our usage style.
Alas, unlike C preprocessor and spec files, we can't use indentation
to make it easier to see how deeply nesting goes.
* cfg.mk (sc_makefile_conditionals): New rule.
* daemon/Makefile.am: Enforce the style.
* gnulib/tests/Makefile.am: Likewise.
* python/Makefile.am: Likewise.
* src/Makefile.am: Likewise.
* tests/Makefile.am: Likewise.
* tools/Makefile.am: Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
The return values for the virConnectListAllSecrets call were not
bounds checked. This is a robustness issue for clients if
something where to cause corruption of the RPC stream data.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The return values for the virConnectListAllNWFilters call were not
bounds checked. This is a robustness issue for clients if
something where to cause corruption of the RPC stream data.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The return values for the virConnectListAllNodeDevices call were not
bounds checked. This is a robustness issue for clients if
something where to cause corruption of the RPC stream data.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The return values for the virConnectListAllInterfaces call were not
bounds checked. This is a robustness issue for clients if
something where to cause corruption of the RPC stream data.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The return values for the virConnectListAllNetworks call were not
bounds checked. This is a robustness issue for clients if
something where to cause corruption of the RPC stream data.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The return values for the virStoragePoolListAllVolumes call were not
bounds checked. This is a robustness issue for clients if
something where to cause corruption of the RPC stream data.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The return values for the virConnectListAllStoragePools call were not
bounds checked. This is a robustness issue for clients if
something where to cause corruption of the RPC stream data.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The return values for the virConnectListAllDomains call were not
bounds checked. This is a robustness issue for clients if
something where to cause corruption of the RPC stream data.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The return values for the virDomain{SnapshotListAllChildren,ListAllSnapshots}
calls were not bounds checked. This is a robustness issue for clients if
something where to cause corruption of the RPC stream data.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The return values for the virDomainGetJobStats call were not
bounds checked. This is a robustness issue for clients if
something where to cause corruption of the RPC stream data.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
The parameters for the virDomainMigrate*Params RPC calls were
not bounds checks, meaning a malicious client can cause libvirtd
to consume arbitrary memory
This issue was introduced in the 1.1.0 release of libvirt
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
