- 30 6月, 2016 1 次提交
-
-
由 Jiri Denemark 提交于
CVE-2016-5008 Setting an empty graphics password is documented as a way to disable VNC/SPICE access, but QEMU does not always behaves like that. VNC would happily accept the empty password. Let's enforce the behavior by setting password expiration to "now". https://bugzilla.redhat.com/show_bug.cgi?id=1180092Signed-off-by: NJiri Denemark <jdenemar@redhat.com> (cherry picked from commit bb848fee)
-
- 13 12月, 2015 1 次提交
-
-
由 Eric Blake 提交于
The libvirt file system storage driver determines what file to act on by concatenating the pool location with the volume name. If a user is able to pick names like "../../../etc/passwd", then they can escape the bounds of the pool. For that matter, virStoragePoolListVolumes() doesn't descend into subdirectories, so a user really shouldn't use a name with a slash. Normally, only privileged users can coerce libvirt into creating or opening existing files using the virStorageVol APIs; and such users already have full privilege to create any domain XML (so it is not an escalation of privilege). But in the case of fine-grained ACLs, it is feasible that a user can be granted storage_vol:create but not domain:write, and it violates assumptions if such a user can abuse libvirt to access files outside of the storage pool. Therefore, prevent all use of volume names that contain "/", whether or not such a name is actually attempting to escape the pool. This changes things from: $ virsh vol-create-as default ../../../../../../etc/haha --capacity 128 Vol ../../../../../../etc/haha created $ rm /etc/haha to: $ virsh vol-create-as default ../../../../../../etc/haha --capacity 128 error: Failed to create vol ../../../../../../etc/haha error: Requested operation is not valid: volume name '../../../../../../etc/haha' cannot contain '/' Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 034e47c3)
-
- 03 9月, 2015 4 次提交
-
-
由 Michal Privoznik 提交于
Well, in 8ad126e6 we tried to fix a memory corruption problem. However, the fix was not as good as it could be. I mean, the commit has one line more than it should. I've noticed this output just recently: # ./run valgrind --leak-check=full --show-reachable=yes ./tools/virsh domblklist gentoo ==17019== Memcheck, a memory error detector ==17019== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==17019== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==17019== Command: /home/zippy/work/libvirt/libvirt.git/tools/.libs/virsh domblklist gentoo ==17019== Target Source ------------------------------------------------ fda /var/lib/libvirt/images/fd.img vda /var/lib/libvirt/images/gentoo.qcow2 hdc /home/zippy/tmp/install-amd64-minimal-20150402.iso ==17019== Thread 2: ==17019== Invalid read of size 4 ==17019== at 0x4EFF5B4: virObjectUnref (virobject.c:258) ==17019== by 0x5038CFF: remoteClientCloseFunc (remote_driver.c:552) ==17019== by 0x5069D57: virNetClientCloseLocked (virnetclient.c:685) ==17019== by 0x506C848: virNetClientIncomingEvent (virnetclient.c:1852) ==17019== by 0x5082136: virNetSocketEventHandle (virnetsocket.c:1913) ==17019== by 0x4ECD64E: virEventPollDispatchHandles (vireventpoll.c:509) ==17019== by 0x4ECDE02: virEventPollRunOnce (vireventpoll.c:658) ==17019== by 0x4ECBF00: virEventRunDefaultImpl (virevent.c:308) ==17019== by 0x130386: vshEventLoop (vsh.c:1864) ==17019== by 0x4F1EB07: virThreadHelper (virthread.c:206) ==17019== by 0xA8462D3: start_thread (in /lib64/libpthread-2.20.so) ==17019== by 0xAB441FC: clone (in /lib64/libc-2.20.so) ==17019== Address 0x139023f4 is 4 bytes inside a block of size 240 free'd ==17019== at 0x4C2B1F0: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==17019== by 0x4EA8949: virFree (viralloc.c:582) ==17019== by 0x4EFF6D0: virObjectUnref (virobject.c:273) ==17019== by 0x4FE74D6: virConnectClose (libvirt.c:1390) ==17019== by 0x13342A: virshDeinit (virsh.c:406) ==17019== by 0x134A37: main (virsh.c:950) The problem is, when registering remoteClientCloseFunc(), it's conn->closeCallback which is ref'd. But in the function itself it's conn->closeCallback->conn what is unref'd. This is causing imbalance in reference counting. Moreover, there's no need for the remote driver to increase/decrease conn refcount since it's not used anywhere. It's just merely passed to client registered callback. And for that purpose it's correctly ref'd in virConnectRegisterCloseCallback() and then unref'd in virConnectUnregisterCloseCallback(). Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit e6893007) Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 John Ferlan 提交于
Commit id '7c2d65dd' changed the default value of mode to be -1 if not supplied in the XML, which should cause creation of the volume using the default mode of VIR_STORAGE_DEFAULT_VOL_PERM_MODE; however, the check made was whether mode was '0' or not to use default or provided value. This patch fixes the issue to check if the 'mode' was provided in the XML and use that value. (cherry picked from commit 691dd388)
-
由 John Ferlan 提交于
Commit id '155ca616' added the 'refreshVol' API. In an NFS root-squash environment it was possible that if the just created volume from XML wasn't properly created with the right uid/gid and/or mode, then the followup refreshVol will fail to open the volume in order to get the allocation/ capacity values. This would leave the volume still on the server and cause a libvirtd crash because 'voldef' would be in the pool list, but the cleanup code would free it. (cherry picked from commit db9277a3)
-
由 John Ferlan 提交于
In an NFS root-squashed environment the 'vol-delete' command will fail to 'unlink' the target volume since it was created under a different uid:gid. This code continues the concepts introduced in virFileOpenForked and virDirCreate[NoFork] with respect to running the unlink command under the uid/gid of the child. Unlike the other two, don't retry on EACCES (that's why we're here doing this now). (cherry picked from commit 35847860)
-
- 29 8月, 2015 1 次提交
-
-
由 Jim Fehlig 提交于
This reverts commit 1ce7c1d2, which introduced a significant semantic change to the virDomainGetInfo() API. Additionally, the change was only made to 2 of the 15 virt drivers. Conflicts: src/qemu/qemu_driver.c Signed-off-by: NJim Fehlig <jfehlig@suse.com> (cherry picked from commit 60acb38a)
-
- 17 7月, 2015 1 次提交
-
-
由 Christophe Fergeau 提交于
Currently, when trying to virsh pool-define/virsh pool-build a new 'dir' pool, if the target directory already exists, virsh pool-build/virStoragePoolBuild will error out. This is a change of behaviour compared to eg libvirt 1.2.13 This is caused by the wrong type being used for the dir_create_flags variable in virStorageBackendFileSystemBuild , it's defined as a bool but is used as a flag bit field so should be unsigned int (this matches the type virDirCreate expects for this variable). This should fix https://bugzilla.gnome.org/show_bug.cgi?id=752417 (GNOME Boxes) and https://bugzilla.redhat.com/show_bug.cgi?id=1244080 (downstream virt-manager).
-
- 02 7月, 2015 1 次提交
-
-
由 Michal Privoznik 提交于
So, recently I was testing the LXC driver. You know, startup some domains. But to my surprise, I was not able to start a single one: virsh # start --console test error: Reconnected to the hypervisor error: Failed to start domain test error: internal error: guest failed to start: unexpected exit status 125 So I've start digging. It turns out, that in virExec(), when I printed out the @cmd, I got strange values: *(cmd->outfdptr) was certainly not valid FD number: it has random value of several millions. This obviously made prepareStdFd(childout, STDOUT_FILENO) fail (line 611). But outfdptr is set in virCommandSetOutputFD(). The only place within LXC driver where the function is called is in virLXCProcessBuildControllerCmd(). If you take a closer look at the function it looks like this: static virCommandPtr virLXCProcessBuildControllerCmd(virLXCDriverPtr driver, .. int logfd, const char *pidfile) { ... virCommandSetOutputFD(cmd, &logfd); virCommandSetErrorFD(cmd, &logfd); ... } Yes, you guessed it. @logfd is passed into the function by value. However, in the function we try to get its address (an address of a local variable) which is no longer valid once function is finished and stack is cleaned. Therefore when cmd->outfdptr is evaluated at any point after this function, we may get a random number, depending on what's currently on the stack. Of course, this may work sometimes too - it depends on the compiler how it arranges the code, when the stack is wiped out. In order to fix this, lets pass a pointer to @logfd instead of figuring out (wrong) its value in a function. The bug was introduced in e1de5521. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit 302146b1)
-
- 17 6月, 2015 1 次提交
-
-
由 Eric W. Biederman 提交于
Future kernels will mandate the use of nosuid+nodev+noexec flags when mounting the /proc/sys filesystem. Unconditionally add them now since they don't harm things regardless and could mitigate future security attacks. (cherry picked from commit 24710414)
-
- 01 6月, 2015 1 次提交
-
-
由 Daniel Veillard 提交于
- docs/news.html.in libvirt.spec.in: update for the release - po/*.po*: regenerate
-
- 29 5月, 2015 11 次提交
-
-
由 Ján Tomko 提交于
When attempting to hotplug a virtio-serial console to a domain that had no virtio-serial controllers (not even those that are added by libvirt when some devices need them) at daemon startup, report a user-friendly error: error: Failed to attach device from console.xml error: internal error: no virtio-serial controllers are available instead of crashing the daemon: Process terminating with default action of signal 11 (SIGSEGV): dumping core Access not within mapped region at address 0x8 at 0x531028F: virDomainVirtioSerialAddrNext (domain_addr.c:916) by 0x531028F: virDomainVirtioSerialAddrAssign (domain_addr.c:1029) by 0x1CBF68: qemuDomainAttachChrDevice (qemu_hotplug.c:1565) by 0x1BCD5E: qemuDomainAttachDeviceLive (qemu_driver.c:7997) by 0x1BCD5E: qemuDomainAttachDeviceFlags (qemu_driver.c:8743) Introduced in v1.2.14-30-g59033788.
-
由 Ján Tomko 提交于
Use xmlFreeDoc instead of plain xmlFree. 4 bytes in 1 blocks are definitely lost in loss record 9 of 1,084 at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x70730D6: xmlStrndup (in /usr/lib64/libxml2.so.2.9.2) by 0x701E3DC: xmlNewDoc (in /usr/lib64/libxml2.so.2.9.2) by 0x70C39F8: xmlSAX2StartDocument (in /usr/lib64/libxml2.so.2.9.2) by 0x7017245: xmlParseDocument (in /usr/lib64/libxml2.so.2.9.2) by 0x7017606: xmlDoRead (in /usr/lib64/libxml2.so.2.9.2) by 0x5309DAD: virXMLParseHelper (virxml.c:742) by 0x5367584: virStoragePoolLoadState (storage_conf.c:1863)
-
由 Jim Fehlig 提交于
libxl recently gained support for QXL video device. Support it in the libxl driver too. Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
由 Jim Fehlig 提交于
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
由 Jim Fehlig 提交于
A later change will use the PortAllocator for SPICE too. Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
由 Jim Fehlig 提交于
For HVM domains, vfb info must be populated in the libxl_domain_build_info struct. Currently this is done in the libxlMakeVfbList function, but IMO it would be cleaner to populate the build_info vfb in a separate libxlMakeBuildInfoVfb function. libxlMakeVfbList would then handle only vfb devices, simiar to the other libxlMake<device>List functions. A future patch will extend libxlMakeBuildInfoVfb to support SPICE. Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1224018 The disk pool recalculates the pool allocation, capacity, and available values each time through processing a newly created disk partition. This created an issue with the allocation setting since the code used is shared with the refresh path. Each path calls virStorageBackendDiskReadPartitions which initializes the pool values and then processes the partition table from the 'libvirt_parthelper' utility output with the only difference being create passes a specific volume to be processed while refresh pass a NULL indicating to process all volumes. That passed volume is check during the virStorageBackendDiskMakeVol call to see if the current partition described by the volume key already exists. If it exists, then no adjustments are made to the allocation and the next entry in the output is checked. For the create path this resulted in only the most recently created partition size would be accounted for in the 'allocation' setting. This patch thus checks whether the incoming volume is NULL before clearing the pool allocation value.
-
由 John Ferlan 提交于
Commit id '2ac0e647' for https://bugzilla.redhat.com/show_bug.cgi?id=1206521 was meant to be a generic check for the CreateVol, CreateVolFrom, and DeleteVol paths to check if the storage backend's changed the pool's view of allocation or available values. Unfortunately as it turns out this caused a side effect when the disk backend created an extended partition there would be no actual storage removed from the pool, thus the changes would not find any change in allocation or available and incorrectly update the pool values using the size of the extended partition. A subsequent refresh of the pool would reset the values appropriately. This patch modifies those checks in order to specifically not update the pool allocation and available for only the disk backend rather than be generic before and after checks.
-
由 John Ferlan 提交于
This reverts commit 2ac0e647.
-
由 Laine Stump 提交于
There are also a couple that were very uninformatively just logging the value of the pointer rather than the string itself: * the "name" arg to virNodeDeviceLookupByName() * wwnn and wwpn args to virNodeDeviceLookupSCSIHostByWWN() All char*'s that make sense should now have their contents logged rather than the pointer, and all %s args should now be inside NULLSTR().
-
由 Laine Stump 提交于
In a couple of cases, the node device driver (and the test node device driver which likely copied it) was only logging "Node device not found" when it couldn't find the requested device. This patch changes those cases to log the name (and in the case when it's relevant, the wwnn and wwpn) as well.
-
- 28 5月, 2015 6 次提交
-
-
由 Kothapally Madhu Pavan 提交于
Virsh capabilities will list offline cpus as online when libvirt is compiled with numactl option disabled. This fix will list correct set of online cpus.
-
由 Ján Tomko 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1206114#c5 Reported by: zhenfeng wang <zhwang@redhat.com>
-
由 Ján Tomko 提交于
This never worked. In 0.9.10 when this API was introduced, it was intended that the SHRINK flag combined with DELTA would shrink the volume by the specified capacity (to avoid passing negative numbers). See commit 055bbf45. When the SHRINK flag was finally implemented for the first backend in 1.2.13 (commit aa9aa6a9), it was only implemented for the absolute values and with the delta flag the volume is always extended, regardless of the SHRINK flag. Treat the SHRINK flag as a minus sign when used together with DELTA, to allow shrinking volumes as was documented in the API since 0.9.10. https://bugzilla.redhat.com/show_bug.cgi?id=1220213
-
由 Ján Tomko 提交于
Since shrinking a volume below existing allocation is not allowed, it is not possible for a successful resize with VOL_RESIZE_ALLOCATE to increase the pool's available value. Even with the SHRINK flag it is possible to extend the current allocation or even the capacity. Remove the overflow when computing delta with this flag and do the check even if the flag was specified. https://bugzilla.redhat.com/show_bug.cgi?id=1073305
-
由 Maxim Nestratov 提交于
It is necessary to have unpolluted screen when connecting to parallels driver via virsh. Otherwise a lot of unexpected output one will get on the console. Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>
-
由 Lubomir Rintel 提交于
It's not a problem at all and causes virt-manager to break down. Note: netcf 0.2.8 and earlier generates invalid XML for a bond with no interfaces anyway, so in that case this error in libvirt is never reached since we fail earlier. Signed-off-by: NLubomir Rintel <lkundrak@v3.sk>
-
- 27 5月, 2015 8 次提交
-
-
由 Andrea Bolognani 提交于
The QMP command, like the interrupt reinjection logic it's connected to, is only implemented in QEMU when TARGET_I386 is defined, so checking for its availability on any other architecture is pointless. On the other hand, when we're on x86, we shouldn still make sure that rtc-reset-reinjection is available and refuse to set the time otherwise. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1211938
-
由 Martin Kletzander 提交于
The code already exists there, it just modified different flags. I just noticed this when looking at the code. This patch is better to view with bigger context or '-W'. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Zhang Bo 提交于
When we change system clock to years ago, a certain CPU may use up 100% cputime. The reason is that in function virEventPollCalculateTimeout(), we assign the unsigned long long result to an INT variable, *timeout = then - now; // timeout is INT, and then/now are long long if (*timeout < 0) *timeout = 0; there's a chance that variable @then minus variable @now may be a very large number that overflows INT value expression, then *timeout will be negative and be assigned to 0. Next the 'poll' in function virEventPollRunOnce() will get into an 'endless' while loop there. thus, the cpu that virEventPollRunOnce() thread runs on will go up to 100%. Although as we discussed before in https://www.redhat.com/archives/libvir-list/2015-May/msg00400.html it should be prohibited to set-time while other applications are running, but it does seems to have no harm to make the codes more robust. Signed-off-by: NWang Yufei <james.wangyufei@huawei.com> Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com>
-
由 Roman Bogorodskiy 提交于
Commit 7c2d65dd dropped setting default mode. Update zfs tests accordingly.
-
由 Peter Krempa 提交于
Since commit bcd9a564 virDomainNumatuneGetMode returns the value via a pointer rather than in the return value. The change triggered problems with platforms where the compiler decides to use a data type of size different than integer at the point where we typecast it. Work around the issue by using an intermediate variable of the correct type that gets casted back by the default typecasting rules.
-
由 Luyao Huang 提交于
If the <sysinfo type='smbios'...> ends up not formatting any sub-elements, then rather than formatting as: <sysinfo type='smbios'> </sysinfo> Just format it more cleanly as: <sysinfo type='smbios'/> Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
由 Luyao Huang 提交于
If the redirfilter has no usbdev sub-elements, then do not format anything rather than formatting an empty pair of elements: <redirfilter> </redirfilter> Signed-off-by: NLuyao Huang <lhuang@redhat.com>
-
由 Eric Blake 提交于
Time to update to new gnulib before a release. gcc 5.1 introduced a new -Wformat-signedness, and new gnulib now turns it on by default. However, it is still rather lame at the moment, because it warns for enums, even though there is no way to control the signeness of an enum which does not use any members that are negative or larger than INT_MAX, and even though such an enum would always print the same for both %d and %u: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66249 In file included from ../../src/util/virarch.c:26:0: ../../src/util/virarch.c: In function 'virArchFromHost': ../../src/util/virarch.c:180:15: error: format '%d' expects argument of type 'int', but argument 9 has type 'unsigned int' [-Werror=format=] VIR_DEBUG("Mapped %s to %d (%s)", So this patch turns off the new warning as part of enabling all other new gcc 5.1 warnings that gnulib now enables. * .gnulib: Update to latest, in part for gcc 5.1 interaction. * m4/virt-compile-warnings.m4: Ignore -Wformat-signedness, for now. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 26 5月, 2015 4 次提交
-
-
由 John Ferlan 提交于
Rather than an algorithm based solely on libvirtd ctime to refresh the capabilities add the element of the libvirt build version into the equation. Since that version wouldn't be there prior to this code being run - don't fail on reading the capabilities if not found. In this case, the cache will always be rebuilt when a new libvirt version is installed.
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1195882 Original commit id 'cbde3589' indicates that the cache file would be discarded if either the QEMU binary or libvirtd 'ctime' changes; however, the code only discarded if the QEMU binary time didn't match or if the new libvirtd ctime was later than what created the cache file. Since many factors come into play with 'ctime' adjustments (including perhaps turning back the hands of time), change the logic to also force a refresh if the ctime of libvirt is different than what's in the cache.
-
由 Daniel P. Berrange 提交于
The github project was renamed from libvirtproject to libvirt
-
由 John Ferlan 提交于
Recent changes to the -M/--machine processing code in qemuParseCommandLine caused Coverity to determine there was a possible resource leak with how the 'list' is managed. Rather than try to add virStringFreeList calls everywhere - just promote list to the top of the variables and free it within the error processing code. Also required a couple of other tweaks in order to avoid double free's.
-