I've noticed that in some cases systemd was quick enough and even
if libvirt-guests.service is marked to be started after the
libvirtd.service my guests were not resumed as
libvirt-guests.sh failed to connect. This is because of a
simple fact: systemd correctly starts libvirt-guests after it
execs libvirtd. However, the daemon is not able to accept
connections right from the start. It's doing some
initialization which may take ages. This problem is not limited
to systemd only, indeed. Any init system that is able to startup
services in parallel (e.g. OpenRC) may run into this situation.
The fix is to try connecting not only once, but continuously a few
times with a small sleep in between tries.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
(cherry picked from commit 4e7fc8305a)
Our fixes for CVE-2013-4400 were so effective at "fixing" bugs
in virt-login-shell that we ended up fixing it into a useless
do-nothing program.
Commit 3e2f27e1 picked the name LIBVIRT_SETUID_RPC_CLIENT for
the witness macro when we are doing secure compilation. But
commit 9cd6a57d checked whether the name IN_VIRT_LOGIN_SHELL,
from an earlier version of the patch series, was defined; with
the net result that virt-login-shell invariably detected that
it was setuid and failed virInitialize.
Commit b7fcc799 closed all fds larger than stderr, but in the
wrong place. Looking at the larger context, we mistakenly did
the close in between obtaining the set of namespace fds, then
actually using those fds to switch namespace, which means that
virt-login-shell will ALWAYS fail.
This is the minimal patch to fix the regressions, although
further patches are also worth having to clean up poor
semantics of the resulting program (for example, it is rude to
not pass on the exit status of the wrapped program back to the
invoking shell).
* tools/virt-login-shell.c (main): Don't close fds until after
namespace swap.
* src/libvirt.c (virGlobalInit): Use correct macro.
Signed-off-by: Eric Blake <eblake@redhat.com>
(cherry picked from commit 3d007cb5f8)
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>
(cherry picked from commit 1e4a02bdfe)
The virt-login-shell binary shouldn't need to execute programs
relying on $PATH, but just in case set a fixed $PATH value
of /bin:/usr/bin
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit d665003da1)
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>
(cherry picked from commit 3e2f27e13b)
We don't want to inherit any FDs in the new namespace
except for the stdio FDs. Explicitly close them all,
just in case some do not have the close-on-exec flag
set.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit b7fcc799ad)
'make distcheck' fails from a directory configured --without-lxc:
GEN virt-login-shell.1
Can't write-open ../../tools/virt-login-shell.1: Permission denied at /usr/bin/pod2man line 69.
* tools/Makefile.am (EXTRA_DIST): Ship pre-built man page.
Signed-off-by: Eric Blake <eblake@redhat.com>
It's possible to create a domain which will only use a TLS port
and will not have a non-TLS port set by using:
<graphics type='spice' autoport='yes' defaultMode='secure'/>
In such a setup, the 'graphics' node for the running domain will be:
<graphics type='spice' tlsPort='5900'
autoport='yes' listen='127.0.0.1'
defaultMode='secure'>
However, cmdDomDisplay loops over all the 'graphics' node, and it
ignores nodes which don't have a 'port' attribute. This means
'virsh domdisplay' will only return an empty string for domains
as the one above.
This commit looks for both 'port' and 'tlsPort' before deciding
to ignore a graphics node. It also makes sure 'port' is not printed
when it's not set.
This makes 'virsh domdisplay' return
'spice://127.0.0.1?tls-port=5900' for domains using only a TLS
port.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
After commit 8aecd35126 it'll detect
that a required option is not defined and it will assert and exit with:
virsh.c:1364: vshCommandOpt: Assertion `valid->name' failed.
Problem has been latent since commit ed23b106.
Signed-off-by: Eric Blake <eblake@redhat.com>
completer and completer_flags added to the _vshCmdOptDef
structure so it will be possible for completion generators to
conveniently call option completer functions with desired flags.
Signed-off-by: Eric Blake <eblake@redhat.com>
Some systems apparently have a global variable/function called remove
and thus break compilation of virsh-domain.c. Rename the variable to
avoid this.
Reported by GuanQiang.
Since the maxvcpus command query the maximum number of virtual
CPUs supported for a guest VM on this connection, it should be
in virsh-host.c but not virsh-domain.c.
Signed-off-by: yangdongsheng <yangds.fnst@cn.fujitsu.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1006864
Commit 38ab1225 changed the default value of ret from true to false but
forgot to set ret = true when job is NONE. Thus, virsh domjobinfo
returned 1 when there was no job running for a domain but it used to
(and should) return 0 in this case.
The VIR_FREE() macro will cast away any const-ness. This masked a
number of places where we passed a 'const char *' string to
VIR_FREE. Fortunately in all of these cases, the variable was not
in fact const data, but a heap allocated string. Fix all the
variable declarations to reflect this.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Recent patches to fix handling of Ctrl-C when interacting with
ssh are not portable to mingw, which lacks termios handling.
The simplest solution is to just compile that code out, and
if someone ever appears that has a serious interest in getting
virsh fully functional even with ssh connections, they can
provide patches at that time.
* tools/virsh.h (_vshControl): Make termattr conditional.
* tools/virsh.c (vshTTYIsInterruptCharacter)
(vshTTYDisableInterrupt, vshTTYRestore, cfmakeraw, vshTTYMakeRaw)
(main): Likewise.
Signed-off-by: Eric Blake <eblake@redhat.com>
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 vshWatchJob function registers a SIGINT handler that is used to
abort the active job and does not terminate virsh. Unfortunately, this
breaks when using the ssh transport as SIGINT is sent to the foreground
process group including the ssh transport processes which terminate.
This breaks the connection and migration is left in a insane state.
With this patch the terminal is modified to ignore key binding that
sends SIGINT and does the handling manually.
Resoves: https://bugzilla.redhat.com/show_bug.cgi?id=983348
This patch adds instrumentation to allow modification of config of the
terminal in virsh and successful reset of the state afterwards.
The added helpers allow to disable receiving of SIGINT when pressing the
key sequence (Ctrl+C usualy). This normally sends SIGINT to the
foreground process group which kills ssh processes used for transport of
the data.
When virBufferError is ok in cmdAttachDisk, the latter
should 'goto cleanup', instead of returning a false to
prevent memory leaking.
Signed-off-by: Eric Blake <eblake@redhat.com>
I noticed from an ./autobuild.sh run that we were installing a
virt-login-shell.exe binary when cross-building for mingw,
even though such a binary is necessarily worthless since the
code depends on lxc which is a Linux-only concept.
* tools/Makefile.am (conf_DATA, bin_PROGRAMS, dist_man1_MANS):
Make virt-login-shell installation conditional.
Signed-off-by: Eric Blake <eblake@redhat.com>
Noticed while reviewing another patch that had an accidental
mismatch due to refactoring. An audit of the code showed that
very few callers of vshCommandOpt were expecting a return of
-2, indicating programmer error, and of those that DID check,
they just propagated that status to yet another caller that
did not check. Fix this by making the code blatantly warn
the programmer, rather than silently ignoring it and possibly
doing the wrong thing downstream.
I know that we frown on assert()/abort() inside libvirtd
(libraries should NEVER kill the program that linked them),
but as virsh is an app rather than the library, and as this
is not the first use of assert() in virsh, I think this
approach is okay.
* tools/virsh.h (vshCommandOpt): Drop declaration.
* tools/virsh.c (vshCommandOpt): Make static, and add a
parameter. Abort on programmer errors rather than making callers
repeat that logic.
(vshCommandOptInt, vshCommandOptUInt, vshCommandOptUL)
(vshCommandOptString, vshCommandOptStringReq)
(vshCommandOptLongLong, vshCommandOptULongLong)
(vshCommandOptBool): Adjust callers.
Signed-off-by: Eric Blake <eblake@redhat.com>
Surprisingly, augtool get (or print) returns "path = value" while we are
only interested in the value. We need to remove the "path = " part from
the augtool's output. The following is an example of the augtool command
as used in virt-sanlock-cleanup script:
$ augtool get /files/etc/libvirt/qemu-sanlock.conf/disk_lease_dir
/files/etc/libvirt/qemu-sanlock.conf/disk_lease_dir = /var/lib/libvirt/sanlock
Commit a0b6a36f "fixed" what abfff210 broke (URI precedence), but
there was still one more thing missing to fix. When using virsh
parameters to setup debugging, those weren't honored, because at the
time debugging was initializing, arguments weren't parsed yet. To
make ewerything work as expected, we need to initialize the debugging
twice, once before debugging (so we can debug option parsing properly)
and then again after these options are parsed.
As a side effect, this patch also fixes a leak when virsh is ran with
multiple '-l' parameters.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Since 785ff34bf8 we are using the outputStr variable in cleanup label.
However, there is a possibility to jump to the label before the variable
has been declared:
virsh-pool.c: In function 'cmdPoolList':
virsh-pool.c:1121:25: error: jump skips variable initialization [-Werror=jump-misses-init]
goto asprintf_failure;
^
virsh-pool.c:1308:1: note: label 'asprintf_failure' defined here
asprintf_failure:
^
virsh-pool.c:1267:11: note: 'outputStr' declared here
char *outputStr = NULL;
VIR_FREE(caps) is not enough to free an array allocated
by vshStringToArray.
==17== 4 bytes in 1 blocks are definitely lost in loss record 4 of 728
==17== by 0x4EFFC44: virStrdup (virstring.c:554)
==17== by 0x128B10: _vshStrdup (virsh.c:125)
==17== by 0x129164: vshStringToArray (virsh.c:218)
==17== by 0x157BB3: cmdNodeListDevices (virsh-nodedev.c:409)
https://bugzilla.redhat.com/show_bug.cgi?id=1001536
==23== 41 bytes in 1 blocks are definitely lost in loss record 626 of 727
==23== by 0x4F0099F: virAsprintfInternal (virstring.c:358)
==23== by 0x15D2C9: cmdPoolList (virsh-pool.c:1268)
https://bugzilla.redhat.com/show_bug.cgi?id=1001536
virsh secret-list leak when no secrets are defined:
==27== 8 bytes in 1 blocks are definitely lost in loss record 6 of 726
==27== by 0x4E941DD: virAllocN (viralloc.c:183)
==27== by 0x5037F1A: remoteConnectListAllSecrets (remote_driver.c:3076)
==27== by 0x5004EC6: virConnectListAllSecrets (libvirt.c:16298)
==27== by 0x15F813: vshSecretListCollect (virsh-secret.c:397)
==27== by 0x15F0E1: cmdSecretList (virsh-secret.c:532)
And so do some other *-list commands.
https://bugzilla.redhat.com/show_bug.cgi?id=1001536
The messages were only freed on error.
==12== 1,100 bytes in 1 blocks are definitely lost in loss record 698 of 729
==12== by 0x4E98C22: virBufferAsprintf (virbuffer.c:294)
==12== by 0x12C950: vshOutputLogFile (virsh.c:2440)
==12== by 0x12880B: vshError (virsh.c:2254)
==12== by 0x131957: vshCommandOptDomainBy (virsh-domain.c:109)
==12== by 0x14253E: cmdStart (virsh-domain.c:3333)
https://bugzilla.redhat.com/show_bug.cgi?id=1001536
virsh cpu-stats guest --start 0 --count 3
It outputs right but the return value is 1 rather than 0
echo $?
1
Found by running libvirt-autotest
./run -t libvirt --tests virsh_cpu_stats
