- 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 3 次提交
-
-
由 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 '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)
-
- 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)
-
- 04 5月, 2015 1 次提交
-
-
由 Daniel Veillard 提交于
- docs/news.html.in libvirt.spec.in: update for the release - po/*.po*: regenerated
-
- 01 5月, 2015 2 次提交
-
-
由 John Ferlan 提交于
Found by Laine and discussed a bit on internal IRC. Commit id c56fe7f1 added support for creating a command line to support scsi-disk.channel. Series was here: http://www.redhat.com/archives/libvir-list/2012-February/msg01052.html Which pointed to a design proposal here: http://permalink.gmane.org/gmane.comp.emulators.libvirt/50428 Which states (in part): Libvirt should check for the QEMU "scsi-disk.channel" property. If it is unavailable, QEMU will only support channel=lun=0 and 0<=target<=7. However, the check added was ensuring that bus != lun *and* bus != 0. So if bus == lun and both were non zero, we'd never make the second check. Changing this to an *or* check fixes the check, but still is less readable than the just checking each for 0
-
由 Pavel Hrdina 提交于
This means new libxl-lockd.conf and libxl-sanlock.conf Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
- 30 4月, 2015 6 次提交
-
-
由 Pavel Hrdina 提交于
Recent commit 198cc1d3 introduced integration of lockd and sanlock into libxl, but forget to update libvirt.spec.in to also list new files distributed via package. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Peter Krempa 提交于
Since the qemu capabilities are not initialized for offline VMs the caller might get suboptimal error message: $ virsh blockjob VM PATH --bandwidth 1 error: unsupported configuration: block jobs not supported with this QEMU binary Move the checks after we make sure that the VM is alive.
-
由 Jiri Denemark 提交于
Only USB addresses are allowed for USB disks. Report an error if another address is configured. https://bugzilla.redhat.com/show_bug.cgi?id=1043436Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=858147Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Ján Tomko 提交于
Just as we allow stopping filesystem pools when they were unmounted externally, do not fail to stop an iscsi pool when someone else closed the session externally. Reported at: https://bugzilla.redhat.com/show_bug.cgi?id=1171984
-
由 Jim Fehlig 提交于
Provide integration with libvirt's lock manager in the libxl driver. Signed-off-by: NJim Fehlig <jfehlig@suse.com>
-
- 29 4月, 2015 11 次提交
-
-
由 Cole Robinson 提交于
The phyp driver stuffed it into a DomainDefPtr during its attachdevice routine, but the value is never advertised via capabilities so it should be safe to drop. Have the phyp driver use OSTYPE_LINUX, which is what it advertises via capabilities.
-
由 Michael Chapman 提交于
In qemuMigrationDriveMirror we can start all disk mirrors in parallel. We wait until they are all ready, or one of them aborts. In qemuMigrationCancelDriveMirror, we wait until all mirrors are properly stopped. This is necessary to ensure that destination VM is fully in sync with the (paused) source VM. If a drive mirror can not be cancelled, then the destination is not in a consistent state. In this case it is not safe to continue with the migration. Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
由 Michael Chapman 提交于
The !modern code path needs to call qemuBlockJobEventProcess directly. the modern code path will call it via qemuBlockJobSyncWait. Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
由 Michael Chapman 提交于
Other threads may be blocked in qemuBlockJobSyncWait. Ensure that they're woken up when the domain is stopped. Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
由 Michael Chapman 提交于
qemuBlockJobSyncBegin and qemuBlockJobSyncEnd delimit a region of code where block job events are processed "synchronously". qemuBlockJobSyncWait and qemuBlockJobSyncWaitWithTimeout wait for an event generated by a block job. The Wait* functions may be called multiple times while the synchronous block job is active. Any pending block job event will be processed by only when Wait* or End is called. disk->blockJobStatus is reset by these functions, so if it is needed a pointer to a virConnectDomainEventBlockJobStatus variable should be passed as the last argument. It is safe to pass NULL if you do not care about the block job status. All functions assume the VM object is locked. The Wait* functions will unlock the object for as long as they are waiting. They will return -1 and report an error if the domain exits before an event is received. Typical use is as follows: virQEMUDriverPtr driver; virDomainObjPtr vm; /* locked */ virDomainDiskDefPtr disk; virConnectDomainEventBlockJobStatus status; qemuBlockJobSyncBegin(disk); ... start block job ... if (qemuBlockJobSyncWait(driver, vm, disk, &status) < 0) { /* domain died while waiting for event */ ret = -1; goto error; } ... possibly start other block jobs or wait for further events ... qemuBlockJobSyncEnd(driver, vm, disk, NULL); To perform other tasks periodically while waiting for an event: virQEMUDriverPtr driver; virDomainObjPtr vm; /* locked */ virDomainDiskDefPtr disk; virConnectDomainEventBlockJobStatus status; unsigned long long timeout = 500 * 1000ull; /* milliseconds */ qemuBlockJobSyncBegin(disk); ... start block job ... do { ... do other task ... if (qemuBlockJobSyncWaitWithTimeout(driver, vm, disk, timeout, &status) < 0) { /* domain died while waiting for event */ ret = -1; goto error; } } while (status == -1); qemuBlockJobSyncEnd(driver, vm, disk, NULL); Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
由 Michael Chapman 提交于
We will want to use synchronous block jobs from qemu_migration as well, so split this function out into a new source file. Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
由 Peter Krempa 提交于
While qemu would reject the configuration we can check whether it makes sense to plug the device upfront.
-
由 Peter Krempa 提交于
slot id, if specified, has to be less than the slots count.
-
由 Peter Krempa 提交于
If the added memory device would exceed the maximum memory size, reject it. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1216046
-
由 Peter Krempa 提交于
The documentation states that for shallow block copy the image has to have the same guest visible content as backing file of the current image if the file is being reused. This condition can be achieved also with a raw file (or a qcow without a backing file) so remove the condition that would disallow it. (This patch additionally fixes crash described in https://bugzilla.redhat.com/show_bug.cgi?id=1215569 )
-
由 Maxim Nestratov 提交于
New functions utilize previosly added prlsdkDelDisk and prlsdkGetDiskIndex Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>
-
- 28 4月, 2015 12 次提交
-
-
由 Maxim Nestratov 提交于
Signed-off-by: NMaxim Nestratov <mnestratov@parallels.com>
-
由 Martin Kletzander 提交于
Signed-off-by: NPavel Fedin <p.fedin@samsung.com> Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Zhang Bo 提交于
The free callback should be qemuMonitorChardevInfoFree rather than just 'free' when virHashCreate'ing the chardevInfo hash. ==29959== 24 bytes in 2 blocks are definitely lost in loss record 19 of 53 ==29959== at 0x4C29F80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==29959== by 0xB95C679: strdup (in /lib64/libc-2.20.so) ==29959== by 0x63C6546: virStrdup (virstring.c:709) ==29959== by 0x4805ED: qemuMonitorJSONExtractChardevInfo (qemu_monitor_json.c:3429) ==29959== by 0x4807A5: qemuMonitorJSONGetChardevInfo (qemu_monitor_json.c:3479) ==29959== by 0x434AEC: testQemuMonitorJSONqemuMonitorJSONGetChardevInfo (qemumonitorjsontest.c:1824) ==29959== by 0x436F2F: virtTestRun (testutils.c:211) ==29959== by 0x436932: mymain (qemumonitorjsontest.c:2404) ==29959== by 0x4382EA: virtTestMain (testutils.c:863) ==29959== by 0x436B27: main (qemumonitorjsontest.c:2423) Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com> Signed-off-by: NZhou Yimin <zhouyimin@huawei.com>
-
由 Zhang Bo 提交于
It would be used in qemumonitorjsontest, thus we make it non-static. Signed-off-by: NZhang Bo <oscar.zhangbo@huawei.com> Signed-off-by: NZhou Yimin <zhouyimin@huawei.com>
-
由 Cole Robinson 提交于
Trying to use qemu:///session to create a storage pool pointing at /tmp will usually fail with something like: $ virsh pool-start tmp error: Failed to start pool tmp error: cannot open volume '/tmp/systemd-private-c38cf0418d7a4734a66a8175996c384f-colord.service-kEyiTA': Permission denied If any volume in an FS pool can't be opened by the daemon, the refresh fails, and the pool can't be used. This causes pain for virt-install/virt-manager though. Imaging a user downloads a disk image to /tmp. virt-manager wants to import /tmp as a storage pool, so we can detect what disk format it is, and set the XML correctly. However this case will likely fail as explained above. Change the logic here to skip volumes that fail to open. This could conceivably cause user complaints along the lines of 'why doesn't libvirt show $ROOT-OWNED-VOLUME-FOO', but figuring that currently the pool won't even startup, I don't think there are any current users that care about that case. https://bugzilla.redhat.com/show_bug.cgi?id=1103308
-
由 Cole Robinson 提交于
If you end up with a state file for a pool that no longer starts up or refreshes correctly, the state file is never removed and adds noise to the logs everytime libvirtd is started. If the initial state syncing fails, delete the statefile.
-
由 Cole Robinson 提交于
Will simplify a future patch
-
由 Cole Robinson 提交于
After pool startup we call refreshPool(). If that fails, we leave a stale pool state file hanging around. Hit this trying to create a pool with qemu:///session containing root owned files.
-
qemu:///session由 Cole Robinson 提交于
-
由 John Ferlan 提交于
Replace with just VIR_FREE.
-
由 John Ferlan 提交于
If we received zero iothreads from the monitor, but were perhaps expecting to receive something, then the code was skipping the check to ensure what's in the monitor matches our expectations. So invert the checks to check that what we get back matches expectations and then check there are zero iothreads returned.
-
由 John Ferlan 提交于
Rather than have a separate routine to parse the alias of an iothread returned from qemu in order to get the iothread_id value, parse the alias when returning and just return the iothread_id in qemuMonitorIOThreadInfoPtr This set of patches removes the function, changes the "char *name" to "unsigned int" and handles all the fallout.
-