- 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) (cherry picked from commit d933f68e) (cherry picked from commit 139a4265)
-
- 02 10月, 2014 1 次提交
-
-
由 Pavel Hrdina 提交于
If you use public api virConnectListAllDomains() with second parameter set to NULL to get only the number of domains you will lock out all other operations with domains. Introduced by commit 2c680804. Signed-off-by: NPavel Hrdina <phrdina@redhat.com> (cherry picked from commit fc22b2e7)
-
- 18 9月, 2014 2 次提交
-
-
由 Peter Krempa 提交于
Live definition was used to look up the disk index while persistent one was indexed leading to a crash in qemuDomainGetBlockIoTune. Use the correct def and report a nice error. Unfortunately it's accessible via read-only connection, though it can only crash libvirtd in the cases where the guest is hot-plugging disks without reflecting those changes to the persistent definition. So avoiding hotplug, or doing hotplug where persistent is always modified alongside live definition, will avoid the out-of-bounds access. Introduced in: eca96694a (v0.9.8) Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1140724Reported-by: NLuyao Huang <lhuang@redhat.com> Signed-off-by: NPeter Krempa <pkrempa@redhat.com> (cherry picked from commit 3e745e8f) Conflicts: src/qemu/qemu_driver.c - context due to fewer functions
-
由 Daniel P. Berrange 提交于
If the XML_PARSE_NOENT flag is passed to libxml2, then any entities in the input document will be fully expanded. This allows the user to read arbitrary files on the host machine by creating an entity pointing to a local file. Removing the XML_PARSE_NOENT flag means that any entities are left unchanged by the parser, or expanded to "" by the XPath APIs. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit d6b27d3e)
-
- 03 7月, 2014 1 次提交
-
-
由 Eric Blake 提交于
Newer git doesn't like the maint.mk rule 'public-submodule-commit' run during 'make check', as inherited from our checkout of gnulib. I tracked down that libvirt commit 8531301d picked up a gnulib fix that makes git happy. Rather than try and do a full .gnulib submodule update to gnulib.git d18d1b802 (as used in that libvirt commit), it was easier to just backport the fixed maint.mk from gnulib on top of our existing submodule level. I did it as follows, where these steps will have to be repeated when cherry-picking this commit to any other maintenance branch: mkdir -p gnulib/local/top cd .gnulib git checkout d18d1b802 top/maint.mk git diff HEAD > ../gnulib/local/top/maint.mk.diff git reset --hard cd .. git add gnulib/local/top Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 27 6月, 2014 1 次提交
-
-
由 Eric Blake 提交于
We publish libvirt-api.xml for others to use, and in fact, the libvirt-python bindings use it to generate python constants that correspond to our enum values. However, we had an off-by-one bug that any enum that relied on C's rules for implicit initialization of the first enum member to 0 got listed in the xml as having a value of 1 (and all later members of the enum were equally botched). The fix is simple - since we add one to the previous value when encountering an enum without an initializer, the previous value must start at -1 so that the first enum member is assigned 0. The python generator code has had the off-by-one ever since DV first wrote it years ago, but most of our public enums were immune because they had an explicit = 0 initializer. The only affected enums are: - virDomainEventGraphicsAddressType (such as VIR_DOMAIN_EVENT_GRAPHICS_ADDRESS_IPV4), since commit 987e31ed (libvirt v0.8.0) - virDomainCoreDumpFormat (such as VIR_DOMAIN_CORE_DUMP_FORMAT_RAW), since commit 9fbaff00 (libvirt v1.2.3) - virIPAddrType (such as VIR_IP_ADDR_TYPE_IPV4), since commit 03e0e79e (not yet released) Thanks to Nehal J Wani for reporting the problem on IRC, and for helping me zero in on the culprit function. * docs/apibuild.py (CParser.parseEnumBlock): Fix implicit enum values. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 9b291bbe) Conflicts: docs/apibuild.py - context with 2a409511
-
- 20 3月, 2014 1 次提交
-
-
由 Michal Privoznik 提交于
Currently, we use pthread_sigmask(SIG_BLOCK, ...) prior to calling poll(). This is okay, as we don't want poll() to be interrupted. However, then - immediately as we fall out from the poll() - we try to restore the original sigmask - again using SIG_BLOCK. But as the man page says, SIG_BLOCK adds signals to the signal mask: SIG_BLOCK The set of blocked signals is the union of the current set and the set argument. Therefore, when restoring the original mask, we need to completely overwrite the one we set earlier and hence we should be using: SIG_SETMASK The set of blocked signals is set to the argument set. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit 3d4b4f5a)
-
- 16 1月, 2014 8 次提交
-
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1047577 When writing commit 173c2914, I missed the fact virNetServerClientClose unlocks the client object before actually clearing client->sock and thus it is possible to hit a window when client->keepalive is NULL while client->sock is not NULL. I was thinking client->sock == NULL was a better check for a closed connection but apparently we have to go with client->keepalive == NULL to actually fix the crash. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> (cherry picked from commit 066c8ef6)
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1047577 When a client closes its connection to libvirtd early during virConnectOpen, more specifically just after making REMOTE_PROC_CONNECT_SUPPORTS_FEATURE call to check if VIR_DRV_FEATURE_PROGRAM_KEEPALIVE is supported without even waiting for the result, libvirtd may crash due to a race in keep-alive initialization. Once receiving the REMOTE_PROC_CONNECT_SUPPORTS_FEATURE call, the daemon's event loop delegates it to a worker thread. In case the event loop detects EOF on the connection and calls virNetServerClientClose before the worker thread starts to handle REMOTE_PROC_CONNECT_SUPPORTS_FEATURE call, client->keepalive will be disposed by the time virNetServerClientStartKeepAlive gets called from remoteDispatchConnectSupportsFeature. Because the flow is common for both authenticated and read-only connections, even unprivileged clients may cause the daemon to crash. To avoid the crash, virNetServerClientStartKeepAlive needs to check if the connection is still open before starting keep-alive protocol. Every libvirt release since 0.9.8 is affected by this bug. (cherry picked from commit 173c2914) Conflicts: src/rpc/virnetserverclient.c - older locking style
-
由 Jiri Denemark 提交于
CVE-2013-6458 Every API that is going to begin a job should do that before fetching data from vm->def. (cherry picked from commit 3b564259) Conflicts: src/qemu/qemu_driver.c - older BeginJobWithDriver
-
由 Jiri Denemark 提交于
CVE-2013-6458 Every API that is going to begin a job should do that before fetching data from vm->def. (cherry picked from commit f93d2caa) Conflicts: src/qemu/qemu_driver.c - older style BeginJobWithDriver, context
-
由 Jiri Denemark 提交于
CVE-2013-6458 Generally, every API that is going to begin a job should do that before fetching data from vm->def. However, qemuDomainGetBlockInfo does not know whether it will have to start a job or not before checking vm->def. To avoid using disk alias that might have been freed while we were waiting for a job, we use its copy. In case the disk was removed in the meantime, we will fail with "cannot find statistics for device '...'" error message. (cherry picked from commit b7992595) Conflicts: src/qemu/qemu_driver.c - VIR_STRDUP not backported, context
-
由 Jiri Denemark 提交于
CVE-2013-6458 https://bugzilla.redhat.com/show_bug.cgi?id=1043069 When virDomainDetachDeviceFlags is called concurrently to virDomainBlockStats: libvirtd may crash because qemuDomainBlockStats finds a disk in vm->def before getting a job on a domain and uses the disk pointer after getting the job. However, the domain in unlocked while waiting on a job condition and thus data behind the disk pointer may disappear. This happens when thread 1 runs virDomainDetachDeviceFlags and enters monitor to actually remove the disk. Then another thread starts running virDomainBlockStats, finds the disk in vm->def, and while it's waiting on the job condition (owned by the first thread), the first thread finishes the disk removal. When the second thread gets the job, the memory pointed to be the disk pointer is already gone. That said, every API that is going to begin a job should do that before fetching data from vm->def. (cherry picked from commit db86da5c) Conflicts: src/qemu/qemu_driver.c - context: no ACLs
-
由 Eric Blake 提交于
Newer pod (hello rawhide) complains if you attempt to mix bullets and non-bullets in the same list: virsh.pod around line 3177: Expected text after =item, not a bullet As our intent was to nest an inner list, we make that explicit to keep pod happy. * tools/virsh.pod (ENVIRONMENT): Use correct pod syntax. (cherry picked from commit 00d69b4a)
-
由 Jim Fehlig 提交于
Xen 4.3 fixes a mistake in the libxl event handler signature where the event owned by the application was defined as const. Detect this and define the libvirt libxl event handler signature appropriately. (cherry picked from commit 43b0ff5b) Conflicts: src/libxl/libxl_driver.c - context in formatting
-
- 13 11月, 2013 1 次提交
-
-
由 Ján Tomko 提交于
When opening a new connection to the driver, nwfilterOpen only succeeds if the driverState has been allocated. Move the privilege check in driver initialization before the state allocation to disable the driver. This changes the nwfilter-define error from: error: cannot create config directory (null): Bad address To: this function is not supported by the connection driver: virNWFilterDefineXML https://bugzilla.redhat.com/show_bug.cgi?id=1029266 (cherry picked from commit b7829f95) Conflicts: src/nwfilter/nwfilter_driver.c (da77f04e Convert HAVE_DBUS to WITH_DBUS not backported)
-
- 18 10月, 2013 1 次提交
-
-
由 Zhou Yimin 提交于
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: NZhou Yimin <zhouyimin@huawei.com> Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 9712c251)
-
- 21 9月, 2013 3 次提交
-
-
由 Cole Robinson 提交于
-
由 Guannan Ren 提交于
Resolves:https://bugzilla.redhat.com/show_bug.cgi?id=923053 When cdrom is block type, the virsh change-media failed to insert source info because virsh uses "<source block='/dev/sdb'/>" while the correct name of the attribute for block disks is "dev". (cherry picked from commit 7729a168)
-
由 Gao feng 提交于
libvirt lxc will fail to start when selinux is disabled. error: Failed to start domain noroot error: internal error guest failed to start: PATH=/bin:/sbin TERM=linux container=lxc-libvirt container_uuid=b9873916-3516-c199-8112-1592ff694a9e LIBVIRT_LXC_UUID=b9873916-3516-c199-8112-1592ff694a9e LIBVIRT_LXC_NAME=noroot /bin/sh 2013-01-09 11:04:05.384+0000: 1: info : libvirt version: 1.0.1 2013-01-09 11:04:05.384+0000: 1: error : lxcContainerMountBasicFS:546 : Failed to mkdir /sys/fs/selinux: No such file or directory 2013-01-09 11:04:05.384+0000: 7536: info : libvirt version: 1.0.1 2013-01-09 11:04:05.384+0000: 7536: error : virLXCControllerRun:1466 : error receiving signal from container: Input/output error 2013-01-09 11:04:05.404+0000: 7536: error : virCommandWait:2287 : internal error Child process (ip link del veth1) unexpected exit status 1: Cannot find device "veth1" fix this problem by checking if selinuxfs is mounted in host before we try to create dir /sys/fs/selinux. Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com> (cherry picked from commit 8d63af22)
-
- 19 9月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
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 158ba873 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: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit e7f400a1) Conflicts: daemon/remote.c - context
-
- 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) Signed-off-by: NEric Blake <eblake@redhat.com> Conflicts: configure.ac - context libvirt.spec.in - context of indentation src/access/viraccessdriverpolkit.c - not present on this branch
-
由 Daniel P. Berrange 提交于
Since PIDs can be reused, polkit prefers to be given a (PID,start time) pair. If given a PID on its own, it will attempt to lookup the start time in /proc/pid/stat, though this is subject to races. It is safer if the client app resolves the PID start time itself, because as long as the app has the client socket open, the client PID won't be reused. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 979e9c56) Signed-off-by: NEric Blake <eblake@redhat.com> Conflicts: src/libvirt_private.syms - not backported src/locking/lock_daemon.c - not backported src/rpc/virnetserverclient.c src/rpc/virnetsocket.c src/rpc/virnetsocket.h src/util/viridentity.h - not backported src/util/virprocess.c src/util/virprocess.h src/util/virstring.c src/util/virstring.h Most conflicts were contextual (this patch adds new functions, but upstream intermediate patches not backported here also added new features, and the resolution was picking out just the portions needed by this commit). virnetsocket.c also had slightly different locking semantics.
-
由 Matthias Bolte 提交于
Currently virNetSocketNew fails because virSetCloseExec fails as there is no proper implementation for it on Windows at the moment. Workaround this by pretending that setting close-on-exec on the fd works. This can be done because libvirt currently lacks the ability to create child processes on Windows anyway. So there is no point in failing to set a flag that isn't useful at the moment anyway. (cherry picked from commit fcfa4bfb)
-
- 16 9月, 2013 1 次提交
-
-
由 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) Conflicts: src/conf/domain_conf.c
-
- 29 8月, 2013 1 次提交
-
-
由 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> (cherry picked from commit 745aa55f)
-
- 20 8月, 2013 2 次提交
-
-
由 Peter Krempa 提交于
The virBitmapParse function was calling virBitmapIsSet() function that requires the caller to check the bounds of the bitmap without checking them. This resulted into crashes when parsing a bitmap string that was exceeding the bounds used as argument. This patch refactors the function to use virBitmapSetBit without checking if the bit is set (this function does the checks internally) and then counts the bits in the bitmap afterwards (instead of keeping track while parsing the string). This patch also changes the "parse_error" label to a more common "error". The refactor should also get rid of the need to call sa_assert on the returned variable as the callpath should allow coverity to infer the possible return values. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=997367 Thanks to Alex Jia for tracking down the issue. This issue is introduced by commit 0fc89098. (cherry picked from commit 47b9127e) Conflicts: src/util/bitmap.c - context, coverity fix not backported
-
由 Eric Blake 提交于
Sometimes it's handy to know how many bits are set. * src/util/bitmap.h (virBitmapCountBits): New prototype. (virBitmapNextSetBit): Use correct type. * src/util/bitmap.c (virBitmapNextSetBit): Likewise. (virBitmapSetAll): Maintain invariant of clear tail bits. (virBitmapCountBits): New function. * src/libvirt_private.syms (bitmap.h): Export it. * tests/virbitmaptest.c (test2): Test it. (cherry picked from commit 0711c4b7)
-
- 02 8月, 2013 2 次提交
-
-
由 Cole Robinson 提交于
-
由 Ján Tomko 提交于
Call virLogVMessage instead of virLogMessage, since libudev called us with a va_list object, not a list of arguments. Honor message priority and strip the trailing newline. https://bugzilla.redhat.com/show_bug.cgi?id=969152 (cherry picked from commit f753dd62) Conflicts: src/libvirt_private.syms src/node_device/node_device_udev.c src/util/logging.c src/util/logging.h
-
- 23 7月, 2013 7 次提交
-
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=964358 Attempts to start a domain with both SELinux and DAC security modules loaded will deadlock; latent problem introduced in commit fdb3bde3 and exposed in commit 29fe5d74. Basically, when recursing into the security manager for other driver's prefork, we have to undo the asymmetric lock taken at the manager level. Reported by Jiri Denemark, with diagnosis help from Dan Berrange. * src/security/security_stack.c (virSecurityStackPreFork): Undo extra lock grabbed during recursion. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit bfc183c1)
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=964358 Commit 75c12564 states that virGetGroupList must not be called between fork and exec, then commit ee777e99 promptly violated that for lxc's use of virSecurityManagerSetProcessLabel. Hoist the supplemental group detection to the time that the security manager needs to fork. Qemu is safe, as it uses virSecurityManagerSetChildProcessLabel which in turn uses virCommand to determine supplemental groups. This does not fix the fact that virSecurityManagerSetProcessLabel calls virSecurityDACParseIds calls parseIds which eventually calls getpwnam_r, which also violates fork/exec async-signal-safe safety rules, but so far no one has complained of hitting deadlock in that case. * src/security/security_dac.c (_virSecurityDACData): Track groups in private data. (virSecurityDACPreFork): New function, to set them. (virSecurityDACClose): Clean up new fields. (virSecurityDACGetIds): Alter signature. (virSecurityDACSetSecurityHostdevLabelHelper) (virSecurityDACSetChardevLabel, virSecurityDACSetProcessLabel) (virSecurityDACSetChildProcessLabel): Update callers. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 29fe5d74) Conflicts: src/security/security_dac.c - virSecurityDACSetSecurityUSBLabel needed similar treatment; no virSecurityDACSetChildPrcessLabel
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=964358 A future patch wants the DAC security manager to be able to safely get the supplemental group list for a given uid, but at the time of a fork rather than during initialization so as to pick up on live changes to the system's group database. This patch adds the framework, including the possibility of a pre-fork callback failing. For now, any driver that implements a prefork callback must be robust against the possibility of being part of a security stack where a later element in the chain fails prefork. This means that drivers cannot do any action that requires a call to postfork for proper cleanup (no grabbing a mutex, for example). If this is too prohibitive in the future, we would have to switch to a transactioning sequence, where each driver has (up to) 3 callbacks: PreForkPrepare, PreForkCommit, and PreForkAbort, to either clean up or commit changes made during prepare. * src/security/security_driver.h (virSecurityDriverPreFork): New callback. * src/security/security_manager.h (virSecurityManagerPreFork): Change signature. * src/security/security_manager.c (virSecurityManagerPreFork): Optionally call into driver, and allow returning failure. * src/security/security_stack.c (virSecurityDriverStack): Wrap the handler for the stack driver. * src/qemu/qemu_process.c (qemuProcessStart): Adjust caller. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit fdb3bde3) Conflicts: src/security/security_manager.c - context from previous backport differences
-
由 Daniel P. Berrange 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=964358 The hook scripts used by virCommand must be careful wrt accessing any mutexes that may have been held by other threads in the parent process. With the recent refactoring there are 2 potential flaws lurking, which will become real deadlock bugs once the global QEMU driver lock is removed. Remove use of the QEMU driver lock from the hook function by passing in the 'virQEMUDriverConfigPtr' instance directly. Add functions to the virSecurityManager to be invoked before and after fork, to ensure the mutex is held by the current thread. This allows it to be safely used in the hook script in the child process. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 61b52d2e) Conflicts: src/libvirt_private.syms - context src/qemu/qemu_process.c - no backport of qemud_driver struct rename src/security/security_manager.c - no backport of making the security driver self-locking; just expose the interface
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=964358 POSIX states that multi-threaded apps should not use functions that are not async-signal-safe between fork and exec, yet we were using getpwuid_r and initgroups. Although rare, it is possible to hit deadlock in the child, when it tries to grab a mutex that was already held by another thread in the parent. I actually hit this deadlock when testing multiple domains being started in parallel with a command hook, with the following backtrace in the child: Thread 1 (Thread 0x7fd56bbf2700 (LWP 3212)): #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136 #1 0x00007fd5761e7388 in _L_lock_854 () from /lib64/libpthread.so.0 #2 0x00007fd5761e7257 in __pthread_mutex_lock (mutex=0x7fd56be00360) at pthread_mutex_lock.c:61 #3 0x00007fd56bbf9fc5 in _nss_files_getpwuid_r (uid=0, result=0x7fd56bbf0c70, buffer=0x7fd55c2a65f0 "", buflen=1024, errnop=0x7fd56bbf25b8) at nss_files/files-pwd.c:40 #4 0x00007fd575aeff1d in __getpwuid_r (uid=0, resbuf=0x7fd56bbf0c70, buffer=0x7fd55c2a65f0 "", buflen=1024, result=0x7fd56bbf0cb0) at ../nss/getXXbyYY_r.c:253 #5 0x00007fd578aebafc in virSetUIDGID (uid=0, gid=0) at util/virutil.c:1031 #6 0x00007fd578aebf43 in virSetUIDGIDWithCaps (uid=0, gid=0, capBits=0, clearExistingCaps=true) at util/virutil.c:1388 #7 0x00007fd578a9a20b in virExec (cmd=0x7fd55c231f10) at util/vircommand.c:654 #8 0x00007fd578a9dfa2 in virCommandRunAsync (cmd=0x7fd55c231f10, pid=0x0) at util/vircommand.c:2247 #9 0x00007fd578a9d74e in virCommandRun (cmd=0x7fd55c231f10, exitstatus=0x0) at util/vircommand.c:2100 #10 0x00007fd56326fde5 in qemuProcessStart (conn=0x7fd53c000df0, driver=0x7fd55c0dc4f0, vm=0x7fd54800b100, migrateFrom=0x0, stdin_fd=-1, stdin_path=0x0, snapshot=0x0, vmop=VIR_NETDEV_VPORT_PROFILE_OP_CREATE, flags=1) at qemu/qemu_process.c:3694 ... The solution is to split the work of getpwuid_r/initgroups into the unsafe portions (getgrouplist, called pre-fork) and safe portions (setgroups, called post-fork). * src/util/virutil.h (virSetUIDGID, virSetUIDGIDWithCaps): Adjust signature. * src/util/virutil.c (virSetUIDGID): Add parameters. (virSetUIDGIDWithCaps): Adjust clients. * src/util/vircommand.c (virExec): Likewise. * src/util/virfile.c (virFileAccessibleAs, virFileOpenForked) (virDirCreate): Likewise. * src/security/security_dac.c (virSecurityDACSetProcessLabel): Likewise. * src/lxc/lxc_container.c (lxcContainerSetID): Likewise. * configure.ac (AC_CHECK_FUNCS_ONCE): Check for setgroups, not initgroups. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit ee777e99) Conflicts: src/lxc/lxc_container.c - did not use setUIDGID before 1.1.0 src/util/virutil.c - oom handling changes not backported; no virSetUIDGIDWithCaps src/util/virfile.c - functions still lived in virutil.c this far back configure.ac - context with previous commit src/util/command.c - no UID/GID handling in vircommand.c... src/storage/storage_backend.c - ...so do it in the one hook user instead
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=964358 Since neither getpwuid_r() nor initgroups() are safe to call in between fork and exec (they obtain a mutex, but if some other thread in the parent also held the mutex at the time of the fork, the child will deadlock), we have to split out the functionality that is unsafe. At least glibc's initgroups() uses getgrouplist under the hood, so the ideal split is to expose getgrouplist for use before a fork. Gnulib already gives us a nice wrapper via mgetgroups; we wrap it once more to look up by uid instead of name. * bootstrap.conf (gnulib_modules): Add mgetgroups. * src/util/virutil.h (virGetGroupList): New declaration. * src/util/virutil.c (virGetGroupList): New function. * src/libvirt_private.syms (virutil.h): Export it. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 75c12564) Conflicts: bootstrap.conf - not updating gnulib submodule... configure.ac - ...so checking for getgrouplist by hand... src/util/virutil.c - ...and copying only the getgrouplist implementation rather than calling the gnulib function; also, file still named util.c src/libvirt_private.syms - context
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=964358 A future patch needs to look up pw_gid; but it is wasteful to crawl through getpwuid_r twice for two separate pieces of information, and annoying to copy that much boilerplate code for doing the crawl. The current internal-only virGetUserEnt is also a rather awkward interface; it's easier to just design it to let callers request multiple pieces of data as needed from one traversal. And while at it, I noticed that virGetXDGDirectory could deref NULL if the getpwuid_r lookup fails. * src/util/virutil.c (virGetUserEnt): Alter signature. (virGetUserDirectory, virGetXDGDirectory, virGetUserName): Adjust callers. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit c1983ba4) Conflicts: src/util/virutil.c - oom reporting/strdup changes not backported
-
- 11 7月, 2013 1 次提交
-
-
由 Ján Tomko 提交于
Don't reuse the return value of virStorageBackendFileSystemIsMounted. If it's 0, we'd return it even if the mount command failed. Also, don't report another error if it's -1, since one has already been reported. Introduced by 258e06c8. https://bugzilla.redhat.com/show_bug.cgi?id=981251 (cherry picked from commit 13fde7ce)
-
- 26 6月, 2013 2 次提交
-
-
由 Ján Tomko 提交于
Don't check for '\n' at the end of file if zero bytes were read. Found by valgrind: ==404== Invalid read of size 1 ==404== at 0x529B09F: virCgroupGetValueStr (vircgroup.c:540) ==404== by 0x529AF64: virCgroupMoveTask (vircgroup.c:1079) ==404== by 0x1EB475: qemuSetupCgroupForEmulator (qemu_cgroup.c:1061) ==404== by 0x1D9489: qemuProcessStart (qemu_process.c:3801) ==404== by 0x18557E: qemuDomainObjStart (qemu_driver.c:5787) ==404== by 0x190FA4: qemuDomainCreateWithFlags (qemu_driver.c:5839) Introduced by 0d0b4098. https://bugzilla.redhat.com/show_bug.cgi?id=978356 (cherry picked from commit 306c49ff)
-
由 Ján Tomko 提交于
Free the old XML strings before overwriting them if the user has chosen to reedit the file or force the redefinition. Found by Alex Jia trying to reproduce another bug: https://bugzilla.redhat.com/show_bug.cgi?id=977430#c3 (cherry picked from commit 1e3a2529)
-