** Description changed:

+ [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>
+  $ 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'/>
+   <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'/>
+   <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.

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

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1726804/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to