[libvirt] [PATCH] AppArmor: allow virt-aa-helper read access to Nova's qcow backing files.

[Michal Prívozník]

On 06/09/2018 09:29 PM, intrigeri+libvirt at boum.org wrote:
> From: intrigeri <intrigeri+libvirt at boum.org>
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 1769 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180610/aab0ec8f/attachment-0001.bin>