[Bug 1726804] Please test proposed package

Corey Bryant corey.bryant at canonical.com
Tue Oct 31 18:04:18 UTC 2017


Hello ChristianEhrhardt, or anyone else affected,

Accepted libvirt into pike-proposed. The package will build now and be
available in the Ubuntu Cloud Archive in a few hours, and then in the
-proposed repository.

Please help us by testing this new package. To enable the -proposed
repository:

  sudo add-apt-repository cloud-archive:pike-proposed
  sudo apt-get update

Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-pike-needed to verification-pike-done. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-pike-failed. In either case, details of your testing
will help us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance!

** Changed in: cloud-archive/pike
       Status: Triaged => Fix Committed

** Tags added: verification-pike-needed

** Changed in: cloud-archive/queens
       Status: Triaged => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to Ubuntu Cloud Archive.
https://bugs.launchpad.net/bugs/1726804

Title:
  rules for images on attach-device not containing lock permission

Status in Ubuntu Cloud Archive:
  Fix Committed
Status in Ubuntu Cloud Archive pike series:
  Fix Committed
Status in Ubuntu Cloud Archive queens series:
  Fix Committed
Status in libvirt package in Ubuntu:
  Fix Committed
Status in libvirt source package in Artful:
  Fix Committed

Bug description:
  [Impact]

   * Qemu 2.10 started to lock image files to ensure no data corruption 
     occurs. Unfurtunately that isn't covered by the apparmor rules we had 
     for images so far - it need to add "k" permission.

   * This was spotted and done in Artful, but the tests for the hot-add of
     disks were hidden behind some other known not-too-bad issues. So by 
     fixing those tests I realized that hot-add of disks is currently broken
     in Artful.

  [Test Case]

  # Get a very minimal Testguest that keeps running to attach something
  $ qemu-img create /tmp/A.img 1M
  cat <<EOF > testguest.xml
  <domain type='kvm'>
          <name>testguest</name>
          <uuid>deadbeef-dead-beef-dead-beefdeadbeef</uuid>
          <memory unit='KiB'>1024</memory>
          <vcpu placement='static'>1</vcpu>
          <os>
                  <type arch='x86_64' machine='pc-i440fx-zesty'>hvm</type>
                  <boot dev='hd'/>
          </os>
          <features>
                  <acpi/>
                  <apic/>
                  <pae/>
          </features>
          <devices>
                  <emulator>/usr/bin/kvm-spice</emulator>
                  <disk type='file' device='disk'>
                          <driver name='qemu'/>
                          <source file='/tmp/A.img'/>
                          <target dev='vda'/>
                  </disk>
          </devices>
          <seclabel type='dynamic' model='apparmor' relabel='yes'/>
  </domain>
  EOF
  $ virsh define testguest.xml
  $ virsh start testguest

  # Prepare Disk
  $ qemu-img create /tmp/F.img 1M
  $ cat <<EOF >diskF.xml
  <disk type='file'>
    <driver name='qemu'/>
    <source file='/tmp/F.img'/>
    <target dev='sdc'/>
  </disk>
  EOF

  # Then attach:
  $ virsh attach-device testguest diskF.xml

  * This should work, but fails without the fix as:
     error: internal error: unable to execute QEMU command 'device_add': 
  Property 'scsi-hd.drive' can't find value 'drive-scsi0-0-0-1'
    With a related apparmor denial:
     apparmor="DENIED" operation="file_lock" profile="libvirt-7d781722-69b7-8801-fe96-caf37b7a8969" name="/tmp/tmpKzZQR0/device_disk.img" pid=17582 comm="qemu" requested_mask="k" denied_mask="k" fsuid=0 ouid=0

  * With the fix the file is rwk and works to be attached

  [Regression Potential]

   * This is only adding apparmor lock permissions to files added after 
     start. Thereby the only thing that comes to mind is if now things are 
     locked that were not before, and thereby cause issues. But OTOH no one 
     but qemu should lock the image files in use - and if someone else does 
     he now correctly sees qemu holding the lock. Seems safe to me.

  [Other Info]
   
   * This is an release/upgrade-regression which should be fixed 
     asap. I already wrote and submitted a fix to upstream, but given that 
     this can break a lot of use cases we ahve to fix fast and reroll in 
     case upstream decides to modify.

  ---

  
  On something like:
   $ virsh attach-device <guest> <xml>

  The rule rendered is:
  "/tmp/B.img" rw,

  This is missing the k flag needed on qemu >=2.10.

  This applies to block and file definitions:
  <disk type='block'>
    <driver name='qemu'/>
    <source dev='/tmp/B.img'/>
    <target dev='sdb'/>
  </disk>
  <disk type='file'>
    <driver name='qemu'/>
    <source file='/tmp/F.img'/>
    <target dev='sdc'/>
  </disk>

  Both are rendered correctly as:
  "/tmp/F.img" rwk,
  If being part of the domain xml instead of being a hot-add.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1726804/+subscriptions



More information about the Ubuntu-openstack-bugs mailing list