[SRU] virt-aa-helper denied access to qcow2 backing file running nova in a snap
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libvirt (Ubuntu) |
Fix Released
|
Medium
|
Corey Bryant | ||
Xenial |
Fix Released
|
Medium
|
Corey Bryant | ||
Zesty |
Fix Released
|
Medium
|
Corey Bryant | ||
Artful |
Fix Released
|
Medium
|
Corey Bryant |
Bug Description
[Impact]
The apparmor profile for virt-aa-helper allows access to qcow2 backing images in some well know locations for OpenStack Nova:
/var/
/var/
/var/
which is great when openstack is installed using deb's from the archive; I'm working on a snap for a Nova hypervisor, and the base images are stored in:
/var/
so instances fail to boot as the generated profile for the instance does not contain access to the backing file as virt-aa-helper is DENIED access to it:
[ 5144.554120] audit: type=1400 audit(147998313
switched virt-aa-helper into complain mode:
[ 5531.325617] audit: type=1400 audit(147998351
and the instance booted successfully.
The actual disk for the instance is covered by:
/**/disk{,.*} r,
unfortunately the base image does not have a nice general-izable path in the same way.
We could do:
/var/**/images/** r,
/var/**/_base/** r,
/var/
which would capture other locations for the openstack instances path in the event that its not the default path for nova.
[Testcase]
Run snap-test from the following to deploy openstack from snaps:
github.
[Regression Potential]
Minimal regression potential, as this augments the existing virt-aa-helper to allow a new path to be accessed.
Changed in libvirt (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → Medium |
tags: | added: virt-aa-helper |
Changed in libvirt (Ubuntu): | |
assignee: | nobody → Corey Bryant (corey.bryant) |
Changed in libvirt (Ubuntu Xenial): | |
status: | New → Triaged |
Changed in libvirt (Ubuntu Zesty): | |
status: | New → Triaged |
importance: | Undecided → Medium |
Changed in libvirt (Ubuntu Xenial): | |
importance: | Undecided → Medium |
Changed in libvirt (Ubuntu Zesty): | |
assignee: | nobody → Corey Bryant (corey.bryant) |
Changed in libvirt (Ubuntu Xenial): | |
assignee: | nobody → Corey Bryant (corey.bryant) |
Changed in libvirt (Ubuntu Artful): | |
status: | Triaged → Fix Released |
summary: |
- virt-aa-helper denied access to qcow2 backing file running nova in a - snap + [SRU] virt-aa-helper denied access to qcow2 backing file running nova in + a snap |
description: | updated |
libvirt already has the ability to inject AppArmor rules into the profile that it generates for a domain when you set/modify the path to a disk image. You can test this manually by running `virsh edit DOMAIN`, adjusting one of the paths in the xml, and then looking at the corresponding change in /etc/apparmor. d/libvirt/ libvirt- *.files.
I'm confused about why this isn't working for you. Maybe you're going through libvirt to set/update the paths to your images?
Can you post a sample XML file and the AppArmor denials that you're seeing when using the XML file?