On 06/09/2018 09:29 PM, intrigeri+libvirt@xxxxxxxx wrote: > From: intrigeri <intrigeri+libvirt@xxxxxxxx> > > As reported on https://bugs.debian.org/892431, without this rule, when launching > a QEMU KVM instance, an error occurs immediately upon launching the QEMU > process such as: > > Could not open backing file: Could not open > '/var/lib/nova/instances/_base/affe96668a4c64ef380ff1c71b4caec17039080e': > Permission denied > > The other instance disk images are already covered by the existing rule: > > /**/disk{,.*} r > --- > examples/apparmor/usr.lib.libvirt.virt-aa-helper | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/examples/apparmor/usr.lib.libvirt.virt-aa-helper b/examples/apparmor/usr.lib.libvirt.virt-aa-helper > index 6869685c05..e32402a904 100644 > --- a/examples/apparmor/usr.lib.libvirt.virt-aa-helper > +++ b/examples/apparmor/usr.lib.libvirt.virt-aa-helper > @@ -50,6 +50,7 @@ profile virt-aa-helper /usr/{lib,lib64}/libvirt/virt-aa-helper { > @{HOME}/** r, > /var/lib/libvirt/images/ r, > /var/lib/libvirt/images/** r, > + /var/lib/nova/instances/_base/* r > /{media,mnt,opt,srv}/** r, > # For virt-sandbox > /{,var/}run/libvirt/**/[sv]d[a-z] r, > I am not convinced this is correct fix. This would fix only some use cases where base image is under /var/lib/nova/.. path. The root cause seems to be virt-aa-helper not putting backing store into the profile but looking into the code it does. So we might need to debug virt-aa-helper adding disks with backing chain instead of blindly allowing some path. Michal
Attachment:
pEpkey.asc
Description: application/pgp-keys
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list