Hi Neil,

1) on what /etc/qemu.ifup (as being the default) actually does
You can look at Debian/Ubuntus script (unchanged since 2013)
https://anonscm.debian.org/cgit/pkg-qemu/qemu.git/tree/debian/qemu-ifup.linux
AFAIK Fedora provides no default, but in most cases it is meant for custom 
scripts anyway, e.g. https://en.wikibooks.org/wiki/QEMU/Networking#qemu-ifup as 
a base to create such.

>From there the TL;DR for Debian/Ubuntu is in the top quote:
 # Script to bring a network (tap) device for qemu up.                          
  
 # The idea is to add the tap device to the same bridge                         
  
 # as we have default routing to.
It has various paths with exit as a no-op e.g. if no bridge is there.


2) Why it works in tests
I outlined several combinations of libvirt and openstack above (see the 
timeline in comment #20) that work well together. If you are on any of those 
your testing will not show issues.
Also the "error" is not this script failing. It very likely would work just 
doing nothing or something useless in the case here (yet it is dangerous to 
rely on that). The issue reported here is that due to the unexpected calling of 
/etc/qemu-ifup (due to now path being not set) the apparmor protection kicks in 
and blocks it. So if you tested on a platform without apparmor or with other 
rules you would not have seen it.
Yet it is correct by apparmor to do so - a user is usually meant to add 
exceptions if needed (as the workaround for Logan does.)


3)
On detection of the fix that lets libvirt handle "" as no-op - to my knowledge 
- there is no externally visible thing to check.
It will be upstream with libvirt 3.1 so you can assume it is there starting 
from this.
But you'll never know who will have it backported or not.


4)
IMHO there is one little piece to the puzzle still missing which is want to 
understand why in Logans case qemu is calling it (as in newer libvirt it should 
do it) - see comment #28.
So I'd have expected libvirt saying "error executing '' or anything like it, 
not the apparmor issue he hit for qemu."
But I'll have to wait on his reply for that.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1665698

Title:
  /etc/qemu-ifup not allowed by apparmor

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1665698/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to