Mocking of the __open_2 function was added in
commit 459f071cac
Author: Michal Privoznik <mprivozn@redhat.com>
Date: Thu Aug 15 16:37:17 2019 +0200
virpcimock: Mock __open_2()
This function only exists in glibc, however, and the mocking code runs
on systems not using glibc, such as FreeBSD. Even Linux hosts might be
using a different libc impl, though we don't actively try to support
that.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The nwfilter XML configs are not merely examples, they are data that is
actively shipped and used in production by users.
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The various distros have the following libxml2 vesions:
CentOS 7: 2.9.1
Debian Stretch: 2.9.4
FreeBSD Ports: 2.9.9
Ubuntu 16.04 LTS: 2.9.3
Based on this sampling, we can reasonably bump libxml2 min
version to 2.9.1
The 'query_raw' struct field was added in version 2.6.28,
so can be assumed to exist.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Historically URIs handled by the remote driver will always connect to
the libvirtd UNIX socket. There will now be one daemon per driver, and
each of these has its own UNIX sockets to connect to.
It will still be possible to run the traditional monolithic libvirtd
though, which will have the original UNIX socket path.
In addition there is a virproxyd daemon that doesn't run any drivers,
but provides proxying for clients accessing libvirt over IP sockets, or
tunnelling to the legacy libvirtd UNIX socket path.
Finally when running inside a daemon, the remote driver must not reject
connections unconditionally. For example, the QEMU driver needs to be
able to connect to the network driver. The remote driver must thus be
willing to handle connections even when inside the daemon, provided no
local driver is registered.
This refactoring enables the remote driver to be able to connect to the
per-driver daemons. The URI parameter "mode" accepts the values "auto",
"direct" and "legacy" to control which daemons are connected to.
The client side libvirt.conf config file also supports a "remote_mode"
setting which is used if the URI parameter is not set.
If neither the config file or URI parameter set a mode, then "auto"
is used, whereby the client looks to see which sockets actually exist
right now.
The remote driver will only ever spawn the per-driver daemons, or
the legacy libvirtd. It won't ever try to spawn virtproxyd, as
that is only there for IP based connectivity, or for access from
legacy remote clients.
If connecting to a remote host over any kind of ssh tunnel, for now we
must assume only the legacy socket exists. A future patch will introduce
a netcat replacement that is tailored for libvirt to make remote
tunnelling easier.
The configure arg '--with-remote-default-mode=legacy|direct' allows
packagers to set a default at build time. If not given, it will default
to legacy mode.
Eventually the default will switch to direct mode. Distros can choose
to do the switch earlier if desired. The main blocker is testing and
suitable SELinux/AppArmor policies.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ssh, libssh, libssh2 & unix transports all need to use a UNIX socket
path, and duplicate some of the same logic for error checking. Pull this
out into a separate method to increase code sharing.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Instead of open-coding a string -> enum conversion, use the enum helpers
for the remote driver transport. The old code uses STRCASEEQ, so we must
force the URI transport to lowercase for sake of back-compatibility.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtproxyd daemon is merely responsible for forwarding RPC calls to
one of the other per-driver daemons. As such, it does not have any
drivers loaded and so regular auto-probing logic will not work. We need
it to be able to handle NULL URIs though, so must implement some kind of
alternative probing logic.
When running as root this is quite crude. If a per-driver daemon is
running, its UNIX socket will exist and we can assume it will accept
connections. If the per-driver daemon is not running, but socket
autostart is enabled, we again just assume it will accept connections.
The is not great, however, because a default install may well have
all sockets available for activation. IOW, the virtxend socket may
exist, despite the fact that the libxl driver will not actually work.
When running as non-root this is slightly easier as we only have two
drivers, QEMU and VirtualBox. These daemons will likely not be running
and socket activation won't be used either, as libvirt spawns the
daemon on demand. So we just check whether the daemon actually is
installed.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When the client has a connection to one of the hypervisor specific
daemons (eg virtqemud), the app may still expect to use the secondary
driver APIs (storage, network, etc). None of these will be registered in
the hypervisor daemon, so we must explicitly open a connection to each
of the daemons for the secondary drivers we need.
We don't want to open these secondary driver connections at the same
time as the primary connection is opened though. That would mean that
establishing a connection to virtqemud would immediately trigger
activation of virtnetworkd, virnwfilterd, etc despite that that these
drivers may never be used by the app.
Thus we only open the secondary driver connections at time of first use
by an API call.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The driver dispatch methods access the priv->conn variables directly.
In future we want to dynamically open the connections for the secondary
driver. Thus we want the methods to call a method to get the connection
handle instead of assuming the private variable is non-NULL.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If the event (un)registration methods are invoked while no connection is
open, they jump to a cleanup block which unlocks a mutex which is not
currently locked.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The driver dispatch methods access the priv->conn variables directly.
In future we want to dynamically open the connections for the secondary
driver. Thus we want the methods to call a method to get the connection
handle instead of assuming the private variable is non-NULL.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The client parameter is always used to get access to the private data
struct.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The admin client now supports addressing the per-driver daemons using
the obvious URI schemes for each daemon. eg virtqemud:///system
virtqemud:///session, etc.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtvzd daemon will be responsible for providing the vz API
driver functionality. The vz driver is still loaded by the main
libvirtd daemon at this stage, so virtvzd must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtbhyved daemon will be responsible for providing the bhyve API
driver functionality. The bhyve driver is still loaded by the main
libvirtd daemon at this stage, so virtbhyved must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtvboxd daemon will be responsible for providing the vbox API
driver functionality. The vbox driver is still loaded by the main
libvirtd daemon at this stage, so virtvboxd must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtlxcd daemon will be responsible for providing the lxc API
driver functionality. The lxc driver is still loaded by the main
libvirtd daemon at this stage, so virtlxcd must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtqemud daemon will be responsible for providing the qemu API
driver functionality. The qemu driver is still loaded by the main
libvirtd daemon at this stage, so virtqemud must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtxend daemon will be responsible for providing the libxl API
driver functionality. The libxl driver is still loaded by the main
libvirtd daemon at this stage, so virtxend must not be running at
the same time.
This naming is slightly different than other drivers. With the libxl
driver, the user still has a 'xen:///system' URI, and we provide it
in a libvirt-daemon-xen RPM, which pulls in a
libvirt-daemon-driver-libxl RPM.
Arguably we could rename the libxl driver to "xen" since it is the
only xen driver we have these days, and that matches how we expose it
to users in the URI naming.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtnwfilterd daemon will be responsible for providing the nwfilter API
driver functionality. The nwfilter driver is still loaded by the main
libvirtd daemon at this stage, so virtnwfilterd must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtnodedevd daemon will be responsible for providing the nodedev API
driver functionality. The nodedev driver is still loaded by the main
libvirtd daemon at this stage, so virtnodedevd must not be running at
the same time.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtstoraged daemon will be responsible for providing the storage API
driver functionality. The storage driver is still loaded by the main
libvirtd daemon at this stage, so virtstoraged must not be running at
the same time.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtinterfaced daemon will be responsible for providing the interface API
driver functionality. The interface driver is still loaded by the main
libvirtd daemon at this stage, so virtinterfaced must not be running at
the same time.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtnetworkd daemon will be responsible for providing the network API
driver functionality. The network driver is still loaded by the main
libvirtd daemon at this stage, so virtnetworkd must not be running at
the same time.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtsecretd daemon will be responsible for providing the secret API
driver functionality. The secret driver is still loaded by the main
libvirtd daemon at this stage, so virtsecretd must not be running at
the same time.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The libvirtd daemon provides the traditional libvirt experience where
all the drivers are in a single daemon, and is accessible over both
local UNIX sockets and remote IP sockets.
In the new world we're having a set of per-driver daemons which will
primarily be accessed locally via their own UNIX sockets.
We still, however, need to allow for case of applications which will
connect to libvirt remotely. These remote connections can be done as
TCP/TLS sockets, or by SSH tunnelling to the UNIX socket.
In the later case, the old libvirt.so clients will only know about
the path to the old libvirtd socket /var/run/libvirt/libvirt-sock,
and not the new driver sockets /var/run/libvirt/virtqemud-sock.
It is also not desirable to expose the main driver specific daemons
over IP directly to minimize their attack service.
Thus the virtproxyd daemon steps into place, to provide TCP/TLS sockets,
and back compat for the old libvirtd UNIX socket path(s). It will then
forward all RPC calls made to the appropriate driver specific daemon.
Essentially it is equivalent to the old libvirtd with absolutely no
drivers registered except for the remote driver (and other stateless
drivers in libvirt.so).
We could have modified libvirtd so none of the drivers are registed
to get the same end result. We could even add a libvirtd.conf parameter
to control whether the drivers are loaded to enable users to switch back
to the old world if we discover bugs in the split-daemon model. Using a
new daemon though has some advantages
- We can make virtproxyd and the virtXXXd per-driver daemons all
have "Conflicts: libvirtd.service" in their systemd unit files.
This will guarantee that libvirtd is never started at the same
time, as this would result in two daemons running the same driver.
Fortunately drivers use locking to protect themselves, but it is
better to avoid starting a daemon we know will conflict.
- It allows us to break CLI compat to remove the --listen parameter.
Both listen_tcp and listen_tls parameters in /etc/libvirtd/virtd.conf
will default to zero. Either TLS or TCP can be enabled exclusively
though virtd.conf without requiring the extra step of adding --listen.
- It allows us to set a strict SELinux policy over virtproxyd. For
back compat the libvirtd policy must continue to allow all drivers
to run. We can't easily give a second policy to libvirtd which
locks it down. By introducing a new virtproxyd we can set a strict
policy for that daemon only.
- It gets rid of the weird naming of having a daemon with "lib" in
its name. Now all normal daemons libvirt ships will have "virt"
as their prefix not "libvirt".
- Distros can more easily choose their upgrade path. They can
ship both sets of daemons in their packages, and choose to
either enable libvirtd, or enable the per-driver daemons and
virtproxyd out of the box. Users can easily override this if
desired by just tweaking which systemd units are active.
After some time we can deprecate use of libvirtd and after some more
time delete it entirely, leaving us in a pretty world filled with
prancing unicorns.
The main downside with introducing a new daemon, and with the
per-driver daemons in general, is figuring out the correct upgrade
path.
The conservative option is to leave libvirtd running if it was
an existing installation. Only use the new daemons & virtproxyd
on completely new installs.
The aggressive option is to disable libvirtd if already running
and activate all the new daemons.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When running in libvirtd, we are happy for any of the drivers to simply
skip their initialization in virStateInitialize, as other drivers are
still potentially useful.
When running in per-driver daemons though, we want the daemon to abort
startup if the driver cannot initialize itself, as the daemon will be
useless without it.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The make logic assumes that the SYSTEMD_UNIT_FILES var can be built from
SYSTEMD_UNIT_FILES_IN by simply dropping the directory prefix and the
.in suffix.
This won't work in future when a single .in unit file can be used to
generate multiple different units.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Prepare for reusing libvirtd socket unit files with other daemons by
making various parts of their config conditionally defined by the make
rules.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The make rules for the systemd socket unit files are all essentially
identical and can be collapsed into a single generic rule. The service
unit file rule can be simplified too.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The same make variables will be useful for building both libvirtd and
the split daemons, so refactor & rename variables to facilitate reuse.
Automake gets annoyed if you define a variable ending LDFLAGS:
src/remote/Makefile.inc.am:53: warning: variable 'REMOTE_DAEMON_LDFLAGS' is defined but no program or
src/remote/Makefile.inc.am:53: library has 'REMOTE_DAEMON' as canonical name (possible typo)
So we trick it by using an LD_FLAGS or LD_ADD suffix instead.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
GNULIB sets $(LIBSOCKET) on mingw to pull in the windows socket
APIs. This is trivially not required, since we don't build libvirtd
on mingw.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Prepare for reusing libvirtd augeas defintions with other daemons by
making the config parameters for IP sockets conditionally defined by
the make rules.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Prepare for reusing libvirtd config to create other daemons by making
the config parameters for IP sockets conditionally defined by the make
rules.
The main libvirtd daemon will retain IP listen ability, but all the
driver specific daemons will be local UNIX sockets only. Apps needing
IP connectivity will connect via the libvirtd daemon which will proxy
to the driver specfic daemon.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Using @VARNAME@ is a normal style of automake, so lets match that.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Prepare for reusing libvirtd source to create other daemons by making
the use of IP sockets conditionally defined by the make rules.
The main libvirtd daemon will retain IP listen ability, but all the
driver specific daemons will be local UNIX sockets only. Apps needing
IP connectivity will connect via the libvirtd daemon which will proxy
to the driver specfic daemon.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Prepare for reusing libvirtd source to create other daemons by making
the driver(s) to load conditionally defined by the make rules.
If nothing is set, all drivers will be loaded, ignoring any missing ones
as historically done.
If MODULE_NAME is set only one driver will be loaded and that one must
succeed.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Prepare for reusing libvirtd source to create other daemons by making
the daemon name conditionally defined by the make rules.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The remote daemon tries to print out its help text in a couple of giant
blocks of text. This has already lead to duplication of the text for the
privileged vs unprivileged execution mode. With the introduction of more
daemons, this text is going to be duplicated many more times with small
variations. This is very unfriendly to translators as they have to
translate approximately the same text many times with small tweaks.
Splitting the text up into individual strings to print means that each
piece will only need translating once. It also gets rid of all the
layout information from the translated strings, so avoids the problem of
translators breaking formatting by mistake.
Reviewed-by: Christophe de Dinechin <dinechin@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Instead of adding generated config files to CLEANFILES and BUILT_SOURCES
in each makefile, add them all at once.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Instead of each subdir containing its own custom rule for checking the
augeas tests, use common rule for all.
The new rule searches both src + build dirs for include files, since
some augeas files will be auto-generated very shortly.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The current make rules are inconsistent about which directory the
augeas test files are created in. Put them all in the same dir as
their source.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We already have a variable that lists all augeas test files, so we can
add everything to CLEANFILES at once.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The augeas-gentest.pl program merges a config file into a augeas
file, saving the output to a new file. It is going to be useful
to further process the output file, and it would be easier if this can
be done with a pipeline, so change augeas-gentest.pl to write to stdout
instead of a file.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The conversion to drop gnulib in the previous patch:
commit 8242ce4f45
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Thu Aug 8 10:23:26 2019 +0100
tools: avoid accidentally using files from gnulib
Missed a few conversions needed for FreeBSD. In particular
netdb.h doesn't pull in sys/socket.h or netinet/in.h
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Use the correct enum constant when validating vlan usage.
This fixes a merge error in
commit 6cb0ec48bd
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Mon Sep 3 17:34:22 2018 +0100
network: convert networkAllocateActualDevice to virNetworkPortDef
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The AM_CPPFLAGS setting includes the gnulib headers, which
means we can get some replacement functions defined. Since
virt-login-shell and the NSS module intentionally don't link
to gnulib, these replacement functions causes link failures.
This was seen cross-compiling on Debian for example:
virt-login-shell.o: In function `main':
/builds/libvirt/libvirt/build/tools/../../tools/virt-login-shell.c:81: undefined reference to `rpl_strerror'
/builds/libvirt/libvirt/build/tools/../../tools/virt-login-shell.c:66: undefined reference to `rpl_strerror'
/builds/libvirt/libvirt/build/tools/../../tools/virt-login-shell.c:75: undefined reference to `rpl_strerror'
The only way to avoid these replacement gnulib headers is
to drop the -Ignulib/lib flags. We do still want to use
gnulib for configmake.h and intprops.h, but those can be
included via their full path.
We must also stop using internal.h, since that expects
-Ignulib/lib to be on the include path in order to resolve
the verify.h header.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that the code does not refer to any libvirt headers,
except internal.h macros, it does not need to link to
any libvirt code, nor gnulib either. The only thing it
needs is yajl.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Use the plain libc APIs to avoid a dependancy on the main libvirt
code from the nss module.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Use the plain libc socket APIs to avoid a dependancy on the main
libvirt code from the nss module.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The .leases file is currently loaded using the virLease class,
which in turn uses the virJSON parsing code. This pulls in a
heap of libvirt code (logging, hash tables, etc) which we do
not wish to depend on.
This uses the yajl parser code directly, so the only dep is
yajl and plain libc functions.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The .macs file is currently loaded using the virMacMap class,
which in turn uses the virJSON parsing code. This pulls in a
heap of libvirt code (logging, hash tables, objects, etc) which
we do not wish to depend on.
This uses the yajl parser code directly, so the only dep is
yajl and plain libc functions.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Build a list of mac addresses immediately, so that later code
searching for leases can be simplified and avoid needing to
use the virMacMap object.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Use the plain libc APIs to avoid a dependancy on the main libvirt
code from the nss module.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Use the plain libc APIs to avoid a dependancy on the main libvirt
code from the nss module.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Use the plain libc APIs to avoid a dependancy on the main libvirt
code from the nss module.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that 100% of libvirt code is forbidden in a SUID environment,
we no longer need to worry about whether env variables are
trustworthy or not. The virt-login-shell setuid program, which
does not link to any libvirt code, will purge all environment
variables, except $TERM, before invoking the virt-login-shell-helper
program which uses libvirt.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that 100% of libvirt code is forbidden in a SUID environment,
we no longer need to worry about whether env variables are
trustworthy or not. The virt-login-shell setuid program, which
does not link to any libvirt code, will purge all environment
variables, except $TERM, before invoking the virt-login-shell-helper
program which uses libvirt.
Thus we only need one API for env passthrough in virCommand.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that none of the libvirt.so code will ever run in a setuid
context, we can remove the virIsSUID() method. The global
initializer function can just inline the check itself. The new
inlined check is slightly stronger as it also looks for a
setgid situation.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virt-login-shell setuid program is now a tiny piece of code
that only uses standard libc functions, and santizes the execution
environment before invoking the real virt-login-shell-helper.
The latter is thus able to use the normal libvirt.so build,
allowing us to delete the special cut down setuid library build.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virt-login-shell binary is a setuid program that takes
no arguments. When invoked it looks at the invoking uid,
resolves it to a username, and finds an LXC guest with the
same name. It then starts the guest and runs the shell in
side the namespaces of the container.
Given this set of tasks the virt-login-shell binary needs
to connect to libvirtd, make various other libvirt API calls.
This is a problem for setuid binaries as various libraries
that libvirt.so links to are not safe. For example, they have
constructor functions which execute an unknown amount of code
that can be influenced by env variables.
For this reason virt-login-shell doesn't use libvirt.so,
but instead links to a custom, cut down, set of source files
sufficient to be a local client only.
This introduces a problem for integrating glib2 into libvirt
though, as once integrated, there would be no way to build
virt-login-shell without an external dependancy on glib2 and
this is definitely not setuid safe.
To resolve this problem, we split the virt-login-shell binary
into two parts. The first part is setuid and does almost
nothing. It simply records the original uid+gid, and then
invokes the virt-login-shell-helper binary. Crucially when
it does this it completes scrubs all environment variables.
It is thus safe for virt-login-shell-helper to link to the
normal libvirt.so. Any things that constructor functions
do cannot be influenced by user control env vars or cli
args.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We'll shortly be renaming the binary to virt-login-shell-helper
and introducing a new tool as virt-login-shell. Renaming the
source file first gives a much more usefull diff for the next
commit.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The public API entry points will call virDispatchError which
will print to stderr by default. We then jump to a cleanup
path which calls virDispatchError again.
We tried to stop the entry points printing to stderr, but
incorrectly called virSetErrorFunc. It needs a real function
that is a no-op, not a NULL function.
Once we fix virSetErrorFunc, then we need to use fprintf in
the cleanup path instead of virDispatchError.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If the 'allowed_users' config setting in virt-login-shell.conf
does not exist, we dereference a NULL pointer resulting in a
crash. We should check for this case and thus ensure the user
is denied access gracefully.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The previous bump to 4.4 was done in:
commit 24241c236e
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Wed Jul 5 10:35:32 2017 +0100
Require use of GCC 4.4 or CLang compilers
with 4.4 picked due to RHEL-6. Since we dropped RHEL-6, the
next oldest distro is RHEL-7 (4.8.5), and thus we pick 4.8
as the new min.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Turning a NULL URI instead the empty string is very misleading when
reading the debug logs as the distinction between the two is
functionally important.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Shutting down the daemon after 30 seconds of being idle is a little bit
too aggressive. Especially when using 'virsh' in single-shot mode, as
opposed to interactive shell mode, it would not be unusual to have
more than 30 seconds between commands. This will lead to the daemon
shutting down and starting up between a series of commands.
Increasing the shutdown timer to 2 minutes will make it less likely that
the daemon will shutdown while the user is in the middle of a series of
commands.
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Instead of having each caller pass in the desired logfile name, pass in
the binary name instead. The logging code can then just derive a logfile
name by appending ".log".
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
On Debian derived distros "localhost" can resolve to the normal
"127.0.0.1" and "::1", but it can also resolve to "127.0.1.1"
Rewrite the code so that it doesn't assume a fixed number of IPs.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Typo meant we use 'nodedev' instead of 'interface'. This doesn't hurt
libvirtd because if a process tries to acquire a lock it already holds
it will succeed. It fails when nodedev & interface drivers are in
separate daemons though.
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When the drivers acquire their pidfile lock we don't want to wait if the
lock is already held. We need the driver to immediately report error,
causing the daemon to exit.
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
With systemd activation the passed in file descriptors are required to
be numbered from STDERR_FILENO + 1 onwards. The unit tests thus require
FDs 3, 4 and 5 to be available.
This may not be the case in all environments in which the tests run. For
example on RHEL7 it was seen that a library constructor (gcrypt probably)
opens /dev/urandom and leaves the file handle open. This means FD 3 is
not available and the activation tests fail.
The best way to deal with this would be to create a standalone helper
program for the tests, but that's much more work than just skipping the
tests if we notice we have the problem.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The use of the virNetServerAutoShutdownFunc typedef was removed in
commit 79b8a56995
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Wed Oct 31 19:03:55 2012 +0000
Replace polling for active VMs with signalling by drivers
This unused typedef was then copied into the virNetDaemon object
when that was split off from virNetServer, resulting in a typedef
virNetDaemonAutoShutdownFunc that has never been needed.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The new systemd activation APIs mean there is no longer a need to get
the UNIX socket path associated with a plain FD.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virGetListenFDs method no longer needs to be called directly, so it
can be a static function internal to the systemd code.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Using the new system activation APIs allows for simpler code setting up
the network services.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Using the new system activation APIs allows for simpler code setting up
the network services.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The only use of this code was removed by:
commit be78814ae0
Author: Michal Privoznik <mprivozn@redhat.com>
Date: Thu Apr 2 14:41:17 2015 +0200
virNetSocketNewConnectUNIX: Use flocks when spawning a daemon
less than a year after it was first introduced in
commit 1b807f92db
Author: Martin Kletzander <mkletzan@redhat.com>
Date: Wed Jul 16 08:00:19 2014 +0200
rpc: pass listen FD to the daemon being started
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Certain libvirtd.conf settings are not honoured when using systemd
socket activation.
Certain systemd unit file settings must match those defined in
libvirtd.conf for systemd socket activation to work with systemd
version < 227, otherwise libvirtd cannot determine which inherited
FD to use for which service.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Since we have socket activation available now, we can let the system
libvirtd exit when it is idle. This allows it to still do autostart
when the host boots up, but when nothing was started it will quickly
exit again until some mgmt app connects to the socket.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We don't do socket activation of libvirtd, since we need to
unconditionally start libvirtd in order to perform autostart. This
doesn't mean we can't have systemd socket units. Some use cases will
not need libvirt's autostart & are thus free to use activation.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virNetServerServiceNewFDOrUNIX method cannot be correctly used when
dealing with systemd activation of a service which can receive more than
one socket FD as there is not guaranteed ordering of FDs.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The current libvirtd code for systemd socket activation assumes socket
FDs are passed in the order unix-rw, unix-ro, unix-admin. There is in
fact no ordering guarantee made by systemd. Applications are expected
to check the address or name associated with each FD to figure out its
identity.
This rewrites libvirtd to make use of the new systemd activation APIs
to make it robust wrt socket ordering changes.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently code has to first create the service and then separately
register it with the server. If the socket associated with a particular
service is not passed from systemd we want to skip creating the service
altogether. This means we can't put the systemd activation logic into
the constructors for virNetServerService.
This patch thus creates some helper methods against virNetServer which
combine systemd activation, service creation and service registration
into one single operation. This operation is automatically a no-op if
systemd activation is present and no sockets were passed in.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently the socket code will unlink any UNIX socket path which is
associated with a server socket. This is not fine grained enough, as we
need to avoid unlinking server sockets we were passed by systemd.
To deal with this we must explicitly track whether each socket needs to
be unlinked when closed, separately of the client vs server state.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virNetServerServiceNewFD API only accepts a single FD, but it is
easily changed to allow for an array of FDs to be passed in.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Introduce a virNetServerServiceNewSocket API that allows the various
constructors to share more code.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When receiving multiple FDs from systemd during service activation it is
neccessary to identify which purpose each FD is used for. While this
could be inferred by looking for the specific IP ports or UNIX socket
paths, this requires the systemd config to always match what is expected
by the code. Using systemd FD names we can remove this restriction and
simply identify FDs based on an arbitrary name.
The FD names are passed by systemd in the LISTEN_FDNAMES env variable
which is populated with the socket unit file names, unless overriden
by using the FileDescriptorName setting.
This is supported since the system 227 release and unfortunately RHEL7
lacks this version. Thus the code has some back compat support whereby
we look at the TCP ports or the UNIX socket paths to identify what
socket maps to which name. This back compat code is written such that
is it easly deleted when we are able to mandate newer systemd.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When the service passed to getaddrinfo is NULL the kernel will choose a
free port to bind to. In a dual stack though we will get separate
sockets for IPv4 and IPv6 and we need them to bind to the same port
number. Thus once the kerel has auto-selected a port for the first
socket, we must disable auto-select for subsequent IP sockets and force
reuse of the first port.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virtlogd config is set to rollover logs every 2 MB.
Normally a logrotate config file is also installed to handle cases where
virtlogd is disabled. This is set to rollover weekly with no size
constraint.
As a result logrotate can interfere with virtlogd's, rolling over files
that virtlogd has already taken care of.
This changes logrotate configs to rollover based on a max size
constraint of 2 MB + 1 byte. When virtlogd is running the log files will
never get this large, making logrotate a no-op.
If the user changes the size in virtlogd's config to something larger,
they are responsible for also changing the logrotate config suitably.
The LXC/libxl drivers don't use virtlogd, but there logrotate config is
altered to match the QEMU driver config, for the sake of consistency.
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Way back in the past, the "no_tty=1" option was added for the remote
driver to disable local password prompting by disabling use of the local
tty:
commit b32f429849
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Fri Sep 21 20:17:09 2007 +0000
Added a no_tty param to remote URIs to stop SSH prompting for password
This was done by adding "-T -o BatchMode=yes -e none" args to ssh. This
achieved the desired results but is none the less semantically flawed
because it is mixing up config parameters for the local tty vs the
remote tty.
The "-T" arg stops allocation of a TTY on the remote host. This is good
for all libvirt SSH tunnels as we never require a TTY for our usage
model, so we should have just passed this unconditionally.
The "-e none" option disables the escape character for sessions with a
TTY. If we pass "-T" this is not required, but it also not harmful to
add it, so we should just pass it unconditionally too.
Only the "-o BatchMode=yes" option is related to disabling local
password prompts and thus needs control via the no_tty URI param.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The getservent() APIs are not re-entrant safe so cannot be used in any
threaded program. Add a wrapper around getaddrinfo() for resolving the
service names to a port number.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Daniel P. Berrangé