Comment 28 for bug 1665698

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

So we have:
- old openstack: sets script=''
- new openstack: sets nothing
- old libvirt: passes to qemu, which does nothing on ''
- new libvirt: executes script, but can't handle ''
- any libvirt: if nothing is set defaults to /etc/qemu-ifup

Instead of the rule to allow that to qemu, I'd prefer to backport the libvirt fix. Because essentially '' does not mean "run qemu/ifup" which would be what the apparmor change allows.
We want back to '' when set really executing nothing.
Well that will at least "allow" it to handle script='' correctly.

IMHO newer openstack is broken as setting nothing implies /etc/qemu-ifup which might not be what they wanted. Never the less from the libvirt perspective we want to allow that.

But here my brain runs into a knot while trying to prep a patch.
In your case Logan, the newer Openstack sets nothing which implies /etc/qemu-ifup.
That should be executed by libvirt which should run under the apparmor profile usr.sbin.libvirtd.
Since you can "fix" your case by adding to the libvirt-qemu abstraction shouldn't that be qemu executing it in your case.

Reading your Deny log again comm="qemu-system-x86".
Hmm, could it be that you run the "new" openstack against the "old" libvirt?
I see you said "with libvirt and non-openstack bits sourced from cloud-archive", but then I'd have expected the apparmor fail against libvirt - if any.

Don't get me wrong we might still want to backport the fix for libvirt, but I want to understand where to fix apparmor rules would be correct.

@Logan:
- Could you report the output of:
  $ dpkg -l 'libvirt-bin' 'libvirt-daemon-system' 'qemu-kvm'
- You said you run Cloud Archive - might I ask which one at the moment?