We don't want setuid programs automatically spawning libvirtd,
so disable any use of autostart when setuid.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 171bb129115d49c567b643acaf20b363b124b8cf)
We don't know enough about quality of external libraries used
for non-UNIX transports, nor do we want to spawn external
commands when setuid. Restrict to the bare minimum which is
UNIX transport for local usage. Users shouldn't need to be
running setuid if connecting to remote hypervisors in any
case.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit e22b0232c7b94aefaef87c52c4d626fa532fcce3)
The use of getenv is typically insecure, and we want people
to use our wrappers, to force them to think about setuid
needs.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 71b21f12bece1127b28b404f11f57b4c2d48983a)
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 1e4a02bdfe6307f93763fa2c9681f280c564aee5)
When running setuid, we must be careful about what env vars
we allow commands to inherit from us. Replace the
virCommandAddEnvPass function with two new ones which do
filtering
virCommandAddEnvPassAllowSUID
virCommandAddEnvPassBlockSUID
And make virCommandAddEnvPassCommon use the appropriate
ones
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 9b8f307c6ad002a17a0510513883d06395636793)
Conflicts:
src/qemu/qemu_command.c
In Fedora 20, libvirt_lxc crashes immediately at startup with a
trace
#0 0x00007f0cddb653ec in free () from /lib64/libc.so.6
#1 0x00007f0ce0e16f4a in virFree (ptrptr=ptrptr@entry=0x7f0ce1830058) at util/viralloc.c:580
#2 0x00007f0ce0e2764b in virResetError (err=0x7f0ce1830030) at util/virerror.c:354
#3 0x00007f0ce0e27a5a in virResetLastError () at util/virerror.c:387
#4 0x00007f0ce0e28858 in virEventRegisterDefaultImpl () at util/virevent.c:233
#5 0x00007f0ce0db47c6 in main (argc=11, argv=0x7fff4596c328) at lxc/lxc_controller.c:2352
Normally virInitialize calls virErrorInitialize and
virThreadInitialize, but we don't link to libvirt.so
in libvirt_lxc, and nor did we ever call the error
or thread initializers.
I have absolutely no idea how this has ever worked, let alone
what caused it to stop working in Fedora 20.
In addition not all code paths from virLogSetFromEnv will
ensure virLogInitialize is called correctly, which is another
possible crash scenario.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 97973ebb7a64a3be6710ddd38d124307991ad7cb)
The log message regex has been
[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}\.[0-9]{3}\+[0-9]{4}: [0-9]+: debug|info|warning|error :
The precedence of '|' is high though, so this is equivalent to matching
[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}\.[0-9]{3}\+[0-9]{4}: [0-9]+: debug
Or
info
Or
warning
Or
error :
Which is clearly not what it should have done. This caused the code to
skip over things which are not log messages. The solution is to simply
add brackets.
A test case is also added to validate correctness.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 5787f0b95ed5a58be020836bda4b27fa3538086c)
Many people will not want the setuid virt-login-shell binary
installed by default, so move it into a separate sub-RPM
named libvirt-login-shell. This RPM is only generated if
LXC is enabled
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 8adc92694fecbd35f28cf236edff14509bf4eaf4)
'make rpm' failed if ~/.rpmmacros contains '%_without_lxc 1',
which simulates the case of not having lxc available.
RPM build errors:
File not found: /home/eblake/rpmbuild/BUILDROOT/libvirt-1.1.1-1.fc19.x86_64/etc/libvirt/virt-login-shell.conf
File not found by glob: /home/eblake/rpmbuild/BUILDROOT/libvirt-1.1.1-1.fc19.x86_64/usr/share/man/man1/virt-login-shell.1*
File not found: /home/eblake/rpmbuild/BUILDROOT/libvirt-1.1.1-1.fc19.x86_64/usr/bin/virt-login-shell
make: *** [rpm] Error 1
Reported by Dan Berrange.
* libvirt.spec.in: Mark virt-login-shell as conditional on lxc.
Signed-off-by: Eric Blake <eblake@redhat.com>
(cherry picked from commit d42906fd004dc4cda34c1d2d4b4c18fce213ede2)
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 d665003da1359410bc4036895a648a7d7256ddaa)
Commit d76227be added functions virDomainCreateWithFiles and
virDomainCreateXMLWithFiles, but there was a little piece missing in
python bindings. This patch fixes proper passing of file descriptors
in the overwrites of these functions.
On systems where gnutls uses libgcrypt, I'm seeing the following
build failure
libvirt.c:314: error: variable 'virTLSThreadImpl' has initializer but incomplete type
libvirt.c:319: error: 'GCRY_THREAD_OPTION_PTHREAD' undeclared here (not in a function)
...
Fix by undefining WITH_GNUTLS_GCRYPT in config-post.h
After commit 3e2f27e1, I've noticed build failures of virt-login-shell
when libapparmor-devel is installed on the build host
CCLD virt-login-shell
../src/.libs/libvirt-setuid-rpc-client.a(libvirt_setuid_rpc_client_la-vircommand.o):
In function `virExec':
/home/jfehlig/virt/upstream/libvirt/src/util/vircommand.c:653: undefined
reference to `aa_change_profile'
collect2: error: ld returned 1 exit status
I was about to commit an easy fix under the build-breaker rule
(build-fix-1.patch), but thought to extend the notion of SECDRIVER_LIBS
to SECDRIVER_CFLAGS, and use both throughout src/Makefile.am where it
makes sense (build-fix-2.patch).
Should I just stick with the simple fix, or is something along the lines
of patch 2 preferred?
Regards,
Jim
>From a0f35945f3127ab70d051101037e821b1759b4bb Mon Sep 17 00:00:00 2001
From: Jim Fehlig <jfehlig@suse.com>
Date: Mon, 21 Oct 2013 15:30:02 -0600
Subject: [PATCH] build: fix virt-login-shell build with apparmor
With libapparmor-devel installed, virt-login-shell fails to link
CCLD virt-login-shell
../src/.libs/libvirt-setuid-rpc-client.a(libvirt_setuid_rpc_client_la-vircommand.o): In function `virExec':
/home/jfehlig/virt/upstream/libvirt/src/util/vircommand.c:653: undefined reference to `aa_change_profile'
collect2: error: ld returned 1 exit status
Fix by linking libvirt_setuid_rpc_client with previously determined
SECDRIVER_LIBS in src/Makefile.am. While at it, introduce SECDRIVER_CFLAGS
and use both throughout src/Makefile.am where it makes sense.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Conflicts:
src/Makefile.am: Context
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 3e2f27e13b94f7302ad948bcacb5e02c859a25fc)
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 b7fcc799ad5d8f3e55b89b94e599903e3c092467)
We must not allow file/syslog/journald log outputs when running
setuid since they can be abused to do bad things. In particular
the 'file' output can be used to overwrite files.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 8c3586ea755c40d5e01b22cb7b5c1e668cdec994)
Care must be taken accessing env variables when running
setuid. Introduce a virGetEnvAllowSUID for env vars which
are safe to use in a setuid environment, and another
virGetEnvBlockSUID for vars which are not safe. Also add
a virIsSUID helper method for any other non-env var code
to use.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit ae53e5d10e434e07079d7e3ba11ec654ba6a256e)
The virConnectDomainXMLToNative API should require 'connect:write'
not 'connect:read', since it will trigger execution of the QEMU
binaries listed in the XML.
Also make virConnectDomainXMLFromNative API require a full
read-write connection and 'connect:write' permission. Although the
current impl doesn't trigger execution of QEMU, we should not
rely on that impl detail from an API permissioning POV.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit 57687fd6bf7f6e1b3662c52f3f26c06ab19dc96c)
Introduced by 7b87a3
When I quit the process which only register VIR_DOMAIN_EVENT_ID_REBOOT,
I got error like:
"libvirt: XML-RPC error : internal error: domain event 0 not registered".
Then I add the following code, it fixed.
Signed-off-by: Zhou Yimin <zhouyimin@huawei.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
(cherry picked from commit 9712c2510ec87a87578576a407768380e250a6a4)
Introduced by commit 3f029fb5319b9dc9cc2fbf8d1ba4505ee9e4b1e3 the RPM build
was broken due to a missing LXC textcase.
Signed-off-by: Daniel Hansel <daniel.hansel@linux.vnet.ibm.com>
(cherry picked from commit 6285c17f790a7e5027aed0207fc5d9eb9130cc0e)
Since 76b644c when the support for RAM filesystems was introduced,
libvirt accepted the following XML:
<source usage='1024' unit='KiB'/>
This was parsed correctly and internally stored in bytes, but it
was formatted as (with an extra 's'):
<source usage='1024' units='KiB'/>
When read again, this was treated as if the units were missing,
meaning libvirt was unable to parse its own XML correctly.
The usage attribute was documented as being in KiB, but it was not
scaled if the unit was missing. Transient domains still worked,
because this was balanced by an extra 'k' in the mount options.
This patch:
Changes the parser to use 'units' instead of 'unit', as the latter
was never documented (fixing persistent domains) and some programs
(libvirt-glib, libvirt-sandbox) already parse the 'units' attribute.
Removes the extra 'k' from the tmpfs mount options, which is needed
because now we parse our own XML correctly.
Changes the default input unit to KiB to match documentation, fixing:
https://bugzilla.redhat.com/show_bug.cgi?id=1015689
(cherry picked from commit 3f029fb5319b9dc9cc2fbf8d1ba4505ee9e4b1e3)
After successful @cmd construction the memory where @keys points to is
part of @cmd. Avoid double freeing it.
(cherry picked from commit 3e8343e1510741623aa5bc1dfb74ec39fde868dd)
After freeing the bitmap pointer, it must set the pointer to NULL.
This will avoid any other use of the freed memory of the bitmap pointer.
https://bugzilla.redhat.com/show_bug.cgi?id=1006710
Signed-off-by: Liuji (Jeremy) <jeremy.liu@huawei.com>
(cherry picked from commit ef5d51d491356f1f4287aa3a8b908b183b6dd9aa)
https://bugzilla.redhat.com/show_bug.cgi?id=1008619
1,003 bytes in 1 blocks are definitely lost in loss record 599 of 635
==404== by 0x50728A7: virBufferAddChar (virbuffer.c:185)
==404== by 0x50BC466: virSystemdEscapeName (virsystemd.c:67)
==404== by 0x50BC6B2: virSystemdMakeSliceName (virsystemd.c:108)
==404== by 0x50BC870: virSystemdCreateMachine (virsystemd.c:169)
==404== by 0x5078267: virCgroupNewMachine (vircgroup.c:1498)
(cherry picked from commit 09b48562aac12387a5ff9ac2f27f9a60490f41ee)
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.
(cherry picked from commit f084caae7c5db8ae03e7fafce164c73f65681843)
Commit 27e81517a87 set the payload size to 256 KB, which is
actually the max packet size, including the size of the header.
Reduce this by VIR_NET_MESSAGE_HEADER_MAX (24) and set
VIR_NET_MESSAGE_LEGACY_PAYLOAD_MAX to 262120, which was the original
value before increasing the limit in commit eb635de1fed.
(cherry picked from commit 609eb987c6cef9082486e66b666f7b9351b783ed)
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>
(cherry picked from commit 27e81517a876dcb738dd8a9bb2e0e68d71c3b7e3)
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>
(cherry picked from commit 8294aa0c1750dcb49d6345cd9bd97bf421580d8b)
Since the wait is done during migration (still inside
QEMU_ASYNC_JOB_MIGRATION_OUT), the code should enter the monitor as such
in order to prohibit all other jobs from interfering in the meantime.
This patch fixes bug #1009886 in which qemuDomainGetBlockInfo was
waiting on the monitor condition and after GetSpiceMigrationStatus
mangled its internal data, the daemon crashed.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1009886
(cherry picked from commit 484cc3217b73b865f00bf42a9c12187b37200699)
The fix for CVE-2013-4311 had a pre-requisite enhancement
to the identity code
commit db7a5688c05f3fd60d9d2b74c72427eb9ee9c176
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Thu Aug 22 16:00:01 2013 +0100
Also store user & group ID values in virIdentity
This had a typo which caused the group ID to overwrite the
user ID string. This meant any checks using this would have
the wrong ID value. This only affected the ACL code, not the
initial polkit auth. It also leaked memory.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit e4697b92abaad16e8e6b41a1e55be9b084d48d5a)
After commit 8aecd351266a66efa59b7f7be77bf66693d99ce0 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>
(cherry picked from commit fe64499dd14315b2d9d62cdf421bd3c97a46b7ac)
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 158ba8730e44b7dd07a21ab90499996c5dec080a
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>
(cherry picked from commit e7f400a110e2e3673b96518170bfea0855dd82c0)
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>
(cherry picked from commit 922b7fda77b094dbf022d625238262ea05335666)
The polkit access driver will want to use the process start
time field. This was already set for network identities, but
not for the system identity.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit e65667c0c6e016d42abea077e31628ae43f57b74)
Future improvements to the polkit code will require access to
the numeric user ID, not merely user name.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
(cherry picked from commit db7a5688c05f3fd60d9d2b74c72427eb9ee9c176)
Bother those kernel developers. In the latest rawhide, kernel
and glibc have now been unified so that <netinet/in.h> and
<linux/in6.h> no longer clash; but <linux/if_bridge.h> is still
not self-contained. Because of the latest header change, the
build is failing with:
checking for linux/param.h... no
configure: error: You must install kernel-headers in order to compile libvirt with QEMU or LXC support
with details:
In file included from conftest.c:561:0:
/usr/include/linux/in6.h:71:18: error: field 'flr_dst' has incomplete type
struct in6_addr flr_dst;
We need a workaround to avoid our workaround :)
* configure.ac (NETINET_LINUX_WORKAROUND): New test.
* src/util/virnetdevbridge.c (includes): Use it.
Signed-off-by: Eric Blake <eblake@redhat.com>
(cherry picked from commit e62e0094dcd0ca1484491a9cc62919473b647f11)
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>
Since virtlockd is only built when libvirtd is built, we should
not install its auxiliary files unconditionally. This solves
two failures. 1. 'make distcheck' complains:
rm -f Makefile
ERROR: files left in build directory after distclean:
./src/virtlockd.8
2. './autobuild.sh' complains:
Checking for unpackaged file(s): /usr/lib/rpm/check-files
/home/eblake/rpmbuild/BUILDROOT/mingw-libvirt-1.1.1-1.fc19.eblake1377879911.x86_64
error: Installed (but unpackaged) file(s) found:
/usr/i686-w64-mingw32/sys-root/mingw/etc/libvirt/virtlockd.conf
/usr/i686-w64-mingw32/sys-root/mingw/share/augeas/lenses/tests/test_virtlockd.aug
/usr/i686-w64-mingw32/sys-root/mingw/share/augeas/lenses/virtlockd.aug
/usr/i686-w64-mingw32/sys-root/mingw/share/man/man8/virtlockd.8
/usr/x86_64-w64-mingw32/sys-root/mingw/etc/libvirt/virtlockd.conf
/usr/x86_64-w64-mingw32/sys-root/mingw/share/augeas/lenses/tests/test_virtlockd.aug
/usr/x86_64-w64-mingw32/sys-root/mingw/share/augeas/lenses/virtlockd.aug
/usr/x86_64-w64-mingw32/sys-root/mingw/share/man/man8/virtlockd.8
* src/Makefile.am (CLEANFILES): Add virtlockd.8.
(man8_MANS, conf_DATA, augeas_DATA, augeastest_DATA): Only install
virtlockd files when daemon is built.
Signed-off-by: Eric Blake <eblake@redhat.com>
'make distcheck' was failing with:
make[3]: Entering directory `/home/eblake/libvirt-tmp2/libvirt-1.1.1/_build/docs'
perl ../../docs/genaclperms.pl ../../src/access/viraccessperm.h > ../../docs/aclperms.htmlinc
/bin/sh: ../../docs/aclperms.htmlinc: Permission denied
when simulating the case of a user doing a VPATH build from a
read-only source tree. The culprit? BUILT_SOURCES are _always_
built, and so must NOT be built into srcdir and need not be part
of the tarball. On the other hand, shipped files must never
depend on files in the builddir. While it would be possible to
fix the problem by generating aclperms.htmlinc into builddir,
we then have the problem that we ship acl.html - we'd have to
rejigger a lot of things to not ship pre-built html. So this
patch goes the other direction - we don't need BUILT_SOURCES,
but instead ensure that we have proper dependencies so that
all files in srcdir are up-to-date at the time the tarball is
created. And because we ship html files in the tarball, that
implies we don't expect users to be able to rebuild them, so
we must not clean any files that would trigger a rebuild except
under the maintainer rules.
* docs/Makefile.am (BUILT_SOURCES): Delete.
(CLEANFILES): Downgrade aclperms.htmlinc cleanup...
(maintainer-clean-local): ...and move hvsupport.html.in...
(MAINTAINERCLEANFILES): ...to a maintainer action.
(hvsupport.html.in): Write into srcdir.
(hvsupport.html): Ensure files are built in order.
(aclperms.htmlinc): Honor silent make.
(EXTRA_DIST): Ship aclperms.htmlinc.
Signed-off-by: Eric Blake <eblake@redhat.com>
With the 1.1.1 tarball, if a user does 'make && make distcheck',
things pass, but if they do 'make distcheck' after 'make clean',
there is an odd failure:
GEN ../../docs/devhelp/index.html
I/O error : Permission denied
I/O error : Permission denied
runtime error: file ../../docs/devhelp/devhelp.xsl line 43 element document
xsltDocumentElem: unable to save to ../../docs/devhelp/libvirt-virterror.html
I/O error : Permission denied
I/O error : Permission denied
This implies that the rules for 'make dist' are missing a
dependency - the generated documentation needs to be up-to-date
before creating the tarball, or else the tarball will be missing
files, where the end user will end up trying to rebuild files in
srcdir, and that fails when srcdir is read-only.
1.1.1 plus this patch now works without issues (other issues have
crept in to 1.1.2-rc1 that prevent 'make distcheck' from working,
but those will be cleaned up in later patches).
* docs/Makefile.am (dist-local): New dependency.
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>
vhost only works in KVM mode at the moment, and is infact compiled
out if the emulator is built for non-native architecture. While it
may work at some point in the future for plain qemu, for now it's
just noise on the command line (and which contributes to arm cli
breakage).
Ubuntu libdbus.so links with -Bsymbolic-functions, which means
that we can only LD_PRELOAD functions that we directly call.
Functions which libdbus.so calls internally can not be replaced.
Thus we cannot use dbus_message_new_error or dbus_message_new_method_return
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>