1. 17 12月, 2019 15 次提交
  2. 13 12月, 2019 2 次提交
    • D
      qemu: honour parseOpaque instead of refetching caps · 8d157c13
      Daniel P. Berrangé 提交于
      The use of the parseOpaque parameter was mistakenly removed in
      
        commit 4a4132b4
        Author: Daniel P. Berrangé <berrange@redhat.com>
        Date:   Tue Dec 3 10:49:49 2019 +0000
      
          conf: don't use passed in caps in post parse method
      
      causing the method to re-fetch qemuCaps that were already just
      fetched and put into parseOpaque.
      
      This is inefficient when parsing incoming XML, but for live
      XML this is more serious as it means we use the capabilities
      for the current QEMU binary on disk, rather than the running
      QEMU.
      
      That commit, however, did have a useful side effect of fixing
      a crasher bug in the qemu post parse callback introduced by
      
        commit 5e939cea
        Author: Jiri Denemark <jdenemar@redhat.com>
        Date:   Thu Sep 26 18:42:02 2019 +0200
      
          qemu: Store default CPU in domain XML
      
      The qemuDomainDefSetDefaultCPU() method in that patch did not
      allow for the possibility that qemuCaps would be NULL and thus
      resulted in a SEGV.
      
      This shows a risk in letting each check in the post parse
      callback look for qemuCaps == NULL. The safer option is to
      check once upfront and immediately stop (postpone) further
      validation.
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      8d157c13
    • D
      qemu: check os type / virt type / arch in validate callback · 87a8b81d
      Daniel P. Berrangé 提交于
      Don't check os type / virt type / arch in the post-parse callback
      because we can't assume qemuCaps is non-NULL at this point. It
      also conceptually belongs to the validation callback.
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      87a8b81d
  3. 12 12月, 2019 2 次提交
    • P
      qemu: fix concurrency crash bug in snapshot revert · d75f865f
      Pavel Mores 提交于
      This commit aims to fix
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1610207
      
      The cause was apparently incorrect handling of jobs in snapshot
      revert code which allowed a thread executing snapshot delete to
      begin job while snapshot revert was still running on another
      thread. The snapshot delete thread then waited on a condition
      variable in qemuMonitorSend() while the revert thread finished,
      changing (and effectively corrupting) the qemuMonitor structure
      under the delete thread which led to its crash.
      
      The incorrect handling of jobs in revert code was due to the fact
      that although qemuDomainRevertToSnapshot() correctly begins a job
      at the start, the job was implicitly ended when qemuProcessStop()
      was called because the job lives in the QEMU driver's private
      data (qemuDomainObjPrivate) that was purged during
      qemuProcessStop().
      
      This fix prevents qemuProcessStop() from clearing jobs as the
      idea of qemuProcessStop() clearing jobs seems wrong in the first
      place. It was (inadvertently) introduced in commit
      888aa4b6, which is effectively reverted by
      the second hunk of this commit. To preserve the desired effects
      of the faulty commit, the first hunk is included as suggested by
      Michal.
      Signed-off-by: NPavel Mores <pmores@redhat.com>
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      d75f865f
    • D
      qemu: keep capabilities when running QEMU as root · 19023562
      Daniel P. Berrangé 提交于
      When QEMU uid/gid is set to non-root this is pointless as if we just
      used a regular setuid/setgid call, the process will have all its
      capabilities cleared anyway by the kernel.
      
      When QEMU uid/gid is set to root, this is almost (always?) never
      what people actually want. People make QEMU run as root in order
      to access some privileged resource that libvirt doesn't support
      yet and this often requires capabilities. As a result they have
      to go find the qemu.conf param to turn this off. This is not
      viable for libguestfs - they want to control everything via the
      XML security label to request running as root regardless of the
      qemu.conf settings for user/group.
      
      Clearing capabilities was implemented originally because there
      was a proposal in Fedora to change permissions such that root,
      with no capabilities would not be able to compromise the system.
      ie a locked down root account. This never went anywhere though,
      and as a result clearing capabilities when running as root does
      not really get us any security benefit AFAICT. The root user
      can easily do something like create a cronjob, which will then
      faithfully be run with full capabilities, trivially bypassing
      the restriction we place.
      
      IOW, our clearing of capabilities is both useless from a security
      POV, and breaks valid use cases when people need to run as root.
      
      This removes the clear_emulator_capabilities configuration
      option from qemu.conf, and always runs QEMU with capabilities
      when root.  The behaviour when non-root is unchanged.
      Reviewed-by: NCole Robinson <crobinso@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      19023562
  4. 11 12月, 2019 1 次提交
  5. 10 12月, 2019 8 次提交
  6. 09 12月, 2019 12 次提交