- 15 10月, 2013 5 次提交
-
-
由 Ján Tomko 提交于
Introduced by 1fa7946f. https://bugzilla.redhat.com/show_bug.cgi?id=1019023 (cherry picked from commit 15fac93b)
-
由 Ján Tomko 提交于
Since 76b644c3 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 3f029fb5)
-
由 Michal Privoznik 提交于
After successful @cmd construction the memory where @keys points to is part of @cmd. Avoid double freeing it. (cherry picked from commit 3e8343e1)
-
由 Liuji (Jeremy) 提交于
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=1006710Signed-off-by: NLiuji (Jeremy) <jeremy.liu@huawei.com> (cherry picked from commit ef5d51d4)
-
由 Ján Tomko 提交于
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 09b48562)
-
- 07 10月, 2013 1 次提交
-
-
由 Claudio Bley 提交于
Commit 27e81517 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 eb635de1. (cherry picked from commit 609eb987)
-
- 01 10月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 27e81517)
-
- 25 9月, 2013 1 次提交
-
-
由 Martin Kletzander 提交于
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 484cc321)
-
- 24 9月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
The fix for CVE-2013-4311 had a pre-requisite enhancement to the identity code commit db7a5688 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: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit e4697b92)
-
- 18 9月, 2013 3 次提交
-
-
由 Daniel P. Berrange 提交于
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: NColin Walters <walters@redhat.com> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 922b7fda)
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit e65667c0)
-
由 Daniel P. Berrange 提交于
Future improvements to the polkit code will require access to the numeric user ID, not merely user name. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit db7a5688)
-
- 17 9月, 2013 1 次提交
-
-
由 Eric Blake 提交于
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: NEric Blake <eblake@redhat.com> (cherry picked from commit e62e0094)
-
- 06 9月, 2013 2 次提交
-
-
由 Guido Günther 提交于
This gives us a RO got, otherwise Debian's lintian complains: W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_storage.so W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_uml.so W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_vbox.so W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_xen.so W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_nwfilter.so W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_storage.so W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_uml.so W: libvirt-sanlock: hardening-no-relro usr/lib/libvirt/lock-driver/sanlock.so (cherry picked from commit f1f0e53b)
-
由 Guido Günther 提交于
(cherry picked from commit fe502de3)
-
- 05 9月, 2013 1 次提交
-
-
由 Michal Privoznik 提交于
The @qemunbd variable can be used uninitialized. (cherry picked from commit 2dba0323)
-
- 02 9月, 2013 1 次提交
-
-
由 John Ferlan 提交于
Remove unused 'cgroup' variable in qemuDomainAttachDeviceDiskLive() to resolve coverity DEADCODE complaint
-
- 31 8月, 2013 2 次提交
-
-
由 Eric Blake 提交于
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: NEric Blake <eblake@redhat.com>
-
由 Cole Robinson 提交于
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).
-
- 30 8月, 2013 2 次提交
-
-
由 Guido Günther 提交于
-
由 Eric Blake 提交于
FreeBSD 10 recently changed their definition of RAND_MAX, to try and cover the fact that their evenly distributed results of rand() really are a smaller range than a full power of 2. As a result, I did some investigation, and learned: 1. POSIX requires random() to be evenly distributed across exactly 31 bits. glibc also guarantees this for rand(), but the two are unrelated, and POSIX only associates RAND_MAX with rand(). Avoiding RAND_MAX altogether thus avoids a build failure on FreeBSD 10. 2. Concatenating random bits from a PRNG will NOT provide uniform coverage over the larger value UNLESS the period of the original PRNG is at least as large as the number of bits being concatenated. Simple example: suppose that RAND_MAX were 1 with a period of 2**1 (which means that the PRNG merely alternates between 0 and 1). Concatenating two successive rand() calls would then invariably result in 01 or 10, which is a rather non-uniform distribution (00 and 11 are impossible) and an even worse period (2**0, since our second attempt will get the same number as our first attempt). But a RAND_MAX of 1 with a period of 2**2 (alternating between 0, 1, 1, 0) provides sane coverage of all four values, if properly tempered. (Back-to-back calls would still only see half the values if we don't do some tempering). We therefore want to guarantee a period of at least 2**64, preferably larger (as a tempering factor); POSIX only makes this guarantee for random() with 256 bytes of info. * src/util/virrandom.c (virRandomBits): Use constants that are accurate for the PRNG we are using, not an unrelated PRNG. (randomState): Ensure the period of our PRNG exceeds our usage. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 29 8月, 2013 15 次提交
-
-
由 Eric Blake 提交于
Commit 29fe5d74 (released in 1.1.1) introduced a latent problem for any caller of virSecurityManagerSetProcessLabel and where the domain already had a uid:gid label to be parsed. Such a setup would collect the list of supplementary groups during virSecurityManagerPreFork, but then ignores that information, and thus fails to call setgroups() to adjust the supplementary groups of the process. Upstream does not use virSecurityManagerSetProcessLabel for qemu (it uses virSecurityManagerSetChildProcessLabel instead), so this problem remained latent until backporting the initial commit into v0.10.2-maint (commit c061ff5e, released in 0.10.2.7), where virSecurityManagerSetChildProcessLabel has not been backported. As a result of using a different code path in the backport, attempts to start a qemu domain that runs as qemu:qemu will end up with supplementary groups unchanged from the libvirtd parent process, rather than the desired supplementary groups of the qemu user. This can lead to failure to start a domain (typical Fedora setup assigns user 107 'qemu' to both group 107 'qemu' and group 36 'kvm', so a disk image that is only readable under kvm group rights is locked out). Worse, it is a security hole (the qemu process will inherit supplemental group rights from the parent libvirtd process, which means it has access rights to files owned by group 0 even when such files should not normally be visible to user qemu). LXC does not use the DAC security driver, so it is not vulnerable at this time. Still, it is better to plug the latent hole on the master branch first, before cherry-picking it to the only vulnerable branch v0.10.2-maint. * src/security/security_dac.c (virSecurityDACGetIds): Always populate groups and ngroups, rather than only when no label is parsed. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
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: NDaniel P. Berrange <berrange@redhat.com>
-
由 Michal Privoznik 提交于
Similarly to qemu_driver.c, we can join often repeating code of looking up network into one function: networkObjFromNetwork. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
When using a <interface type="network"> that points to a network with hostdev forwarding mode a hostdev alias is created for the network. This allias is inserted into the hostdev list, but is backed with a part of the network object that it is connected to. When a VM is being stopped qemuProcessStop() calls networkReleaseActualDevice() which eventually frees the memory for the hostdev object. Afterwards when the domain definition is being freed by virDomainDefFree() an invalid pointer is accessed by virDomainHostdevDefFree() and may cause a crash of the daemon. This patch removes the entry in the hostdev list before freeing the depending memory to avoid this issue. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1000973
-
- 28 8月, 2013 2 次提交
-
-
由 Ján Tomko 提交于
Add checks for updating sections of network definition via virNetworkDefUpdateSection. https://bugzilla.redhat.com/show_bug.cgi?id=989569
-
由 Ján Tomko 提交于
This matches the style we use elsewhere and allows nat-network-dns-srv-record{,-minimal}.xml to be tested in network XML -> XML test.
-
- 27 8月, 2013 2 次提交
-
-
由 Ján Tomko 提交于
QEMU commit 3984890 introduced the "pci-hole64-size" property, to i440FX-pcihost and q35-pcihost with a default setting of 2 GB. Translate <pcihole64>x<pcihole64/> to: -global q35-pcihost.pci-hole64-size=x for q35 machines and -global i440FX-pcihost.pci-hole64-size=x for i440FX-based machines. Error out on other machine types or if the size was specified but the pcihost device lacks 'pci-hole64-size' property. https://bugzilla.redhat.com/show_bug.cgi?id=990418
-
由 Ján Tomko 提交于
<controller type='pci' index='0' model='pci-root'> <pcihole64 unit='KiB'>1048576</pcihole64> </controller> It can be used to adjust (or disable) the size of the 64-bit PCI hole. The size attribute is in kilobytes (different unit can be specified on input), but it gets rounded up to the nearest GB by QEMU. Disabling it will be needed for guests that crash with the 64-bit PCI hole (like Windows XP), see: https://bugzilla.redhat.com/show_bug.cgi?id=990418
-