1. 12 12月, 2019 6 次提交
    • D
      Revert "qemu: directly create virResctrlInfo ignoring capabilities" · 766c8ae9
      Daniel P. Berrangé 提交于
      This reverts commit 7be5fe66.
      
      This commit broke resctrl, because it missed the fact that the
      virResctrlInfoGetCache() has side-effects causing it to actually
      change the virResctrlInfo parameter, not merely get data from
      it.
      
      This code will need some refactoring before we can try separating
      it from virCapabilities again.
      Reviewed-by: NCole Robinson <crobinso@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      766c8ae9
    • A
      ci: Fix VPATH builds · 4af076f1
      Andrea Bolognani 提交于
      The CI build machinery is intentionally not handled by autotools,
      so for VPATH builds - which are mandatory now - we need to make
      sure we're looking into $(srcdir).
      Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      4af076f1
    • 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
    • M
      doc: vtpm only support secrets by UUID at this point · 4bccb996
      Marc-André Lureau 提交于
      Support by usage name can be considered separately (with a 'usage'
      attribute?).
      Reviewed-by: NStefan Berger <stefanb@linux.ibm.com>
      Reviewed-by: NChristophe de Dinechin <dinechin@redhat.com>
      Cc: Stefan Berger <stefanb@linux.ibm.com>
      Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      4bccb996
    • A
      travis: Update name for Ubuntu 18.04 image · 5aab9413
      Andrea Bolognani 提交于
      The corresponding libvirt-jenkins-ci commit is f289e64a5fd9.
      Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      5aab9413
    • 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
  2. 11 12月, 2019 27 次提交
  3. 10 12月, 2019 7 次提交