1. 30 6月, 2016 1 次提交
  2. 13 12月, 2015 1 次提交
    • E
      CVE-2015-5313: storage: don't allow '/' in filesystem volume names · 01cbfeb7
      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)
      01cbfeb7
  3. 03 9月, 2015 3 次提交
    • M
      remoteClientCloseFunc: Don't mangle connection object refcount · 93f51ac2
      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>
      93f51ac2
    • J
      storage: Handle failure from refreshVol · 3c41b3ea
      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)
      3c41b3ea
    • J
      virfile: Introduce virFileUnlink · fe2cf738
      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)
      fe2cf738
  4. 29 8月, 2015 1 次提交
  5. 02 7月, 2015 1 次提交
    • M
      lxc: Don't pass a local variable address randomly · ab1dc5d9
      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)
      ab1dc5d9
  6. 17 6月, 2015 1 次提交
  7. 04 5月, 2015 1 次提交
  8. 01 5月, 2015 2 次提交
  9. 30 4月, 2015 6 次提交
  10. 29 4月, 2015 11 次提交
  11. 28 4月, 2015 12 次提交
新手
引导
客服 返回
顶部