virt-aa-helper doesn't add path for storage pool in AppArmor generated rules

Issue

I'm having a new VM on a new Ubuntu 20.04 host (libvirtd (libvirt) 6.0.0) that fails to start due to AppArmor denying read access to the VM disk. The disk is defined as follows:

<disk type='volume' device='disk'>
  <driver name='qemu' type='qcow2'/>
  <source pool='default' volume='awesome.qcow2'/>
  <target dev='vda' bus='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</disk>
<disk type='file' device='cdrom'>
  <driver name='qemu' type='raw'/>
  <source file='/var/lib/libvirt/images/ubuntu-20.04.1-live-server-amd64.iso'/>
  <target dev='hda' bus='sata'/>
  <readonly/>
  <address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>

During VM startup, it fails with the following message:

error: Failed to start domain playground
error: internal error: qemu unexpectedly closed the monitor: 2020-09-06T20:25:32.047663Z qemu-system-x86_64: -blockdev {"driver":"file","filename":"/var/lib/libvirt/images/awesome.qcow2","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}: Could not open '/var/lib/libvirt/images/awesome.qcow2': Permission denied

Permissions are correct, I have verified it by disabling AppArmor and also the following is printed in the kernel logs:

[10757.098291] audit: type=1400 audit(1599423932.042:131): apparmor="DENIED" operation="open" profile="libvirt-b68582b8-0f35-4298-afd8-45c89ff3cbaa" name="/var/lib/libvirt/images/awesome.qcow2" pid=8654 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=64055

Looking at the profile generated by virt-aa-helper in /etc/apparmor.d/libvirt/ (while the VM is starting up), I can see the following contents:

# DO NOT EDIT THIS FILE DIRECTLY. IT IS MANAGED BY LIBVIRT.
  "/var/log/libvirt/**/playground.log" w,
  "/var/lib/libvirt/qemu/domain-playground/monitor.sock" rw,
  "/var/lib/libvirt/qemu/domain-17-playground/*" rw,
  "/run/libvirt/**/playground.pid" rwk,
  "/run/libvirt/**/*.tunnelmigrate.dest.playground" rw,
  "/var/lib/libvirt/images/ubuntu-20.04.1-live-server-amd64.iso" rk,
  "/dev/vhost-net" rw,
  "/var/lib/libvirt/qemu/domain-17-playground/{,**}" rwk,
  "/var/lib/libvirt/qemu/channel/target/domain-17-playground/{,**}" rwk,
  "/var/lib/libvirt/qemu/domain-17-playground/master-key.aes" rwk,
  "/dev/net/tun" rwk,

For some reason, the path of the the disk is missing, while the ISO is correctly added. I can see the path of the default pool in /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper:

[...]
@{HOME}/ r,
@{HOME}/** r,
/var/lib/libvirt/images/ r,
/var/lib/libvirt/images/** r,
# nova base images (LP: #907269)
/var/lib/nova/images/** r,
[...]

I suspect there should be an entry to the disk file in the volume. Why doesn't virt-aa-helper add it?

Solution

This seems to be a confirmed bug in the libvirt package in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1677398

Answered By - giannoug