[Bug 1665698] Re: /etc/qemu-ifup not allowed by apparmor
ChristianEhrhardt
1665698 at bugs.launchpad.net
Mon Mar 13 08:09:54 UTC 2017
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
OpenStack, which is subscribed to Ubuntu Cloud Archive.
https://bugs.launchpad.net/bugs/1665698
Title:
/etc/qemu-ifup not allowed by apparmor
Status in Ubuntu Cloud Archive:
Incomplete
Status in libvirt package in Ubuntu:
Incomplete
Bug description:
I have VMs failing to start with 2017-02-17 15:38:44.458 264015 ERROR
nova.compute.manager [instance: 0c97ab16-2d30-43fa-b0e4-a064a842b5ed]
libvirtError: internal error: process exited while connecting to
monitor: 2017-02-17T15:38:43.907222Z qemu-system-x86_64: -netdev
tap,ifname=tapf34ef99e-18,id=hostnet0,vhost=on,vhostfd=28: network
script /etc/qemu-ifup failed with status 256
Log excerpt:
http://cdn.pasteraw.com/b3tw4cjefomfi3e9k09hvodrfun85z
Seems to be that /etc/qemu-ifup is being blocked by apparmor:
type=AVC msg=audit(1487347189.015:28536): apparmor="DENIED" operation="exec" profile="libvirt-4a03fea7-e966-48e4-80ac-aa138db67243" name="/etc/qemu-ifup" pid=285438 comm="qemu-system-x86" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
type=PATH msg=audit(1487347189.015:28536): item=0 name="/etc/qemu-ifup" inode=66403 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
root at ubuntu-trusty-5773:/etc/apparmor.d/abstractions# cat /etc/apparmor.d/libvirt/libvirt-4a03fea7-e966-48e4-80ac-aa138db67243
#
# This profile is for the domain whose UUID matches this file.
#
#include <tunables/global>
profile libvirt-4a03fea7-e966-48e4-80ac-aa138db67243 {
#include <abstractions/libvirt-qemu>
#include <libvirt/libvirt-4a03fea7-e966-48e4-80ac-aa138db67243.files>
}
root at ubuntu-trusty-5773:/etc/apparmor.d/abstractions# cat /etc/apparmor.d/libvirt/libvirt-4a03fea7-e966-48e4-80ac-aa138db67243.files
# DO NOT EDIT THIS FILE DIRECTLY. IT IS MANAGED BY LIBVIRT.
"/var/log/libvirt/**/instance-00000008.log" w,
"/var/lib/libvirt/qemu/domain-instance-00000008/monitor.sock" rw,
"/var/run/libvirt/**/instance-00000008.pid" rwk,
"/run/libvirt/**/instance-00000008.pid" rwk,
"/var/run/libvirt/**/*.tunnelmigrate.dest.instance-00000008" rw,
"/run/libvirt/**/*.tunnelmigrate.dest.instance-00000008" rw,
"/var/lib/nova/instances/4a03fea7-e966-48e4-80ac-aa138db67243/console.log" rw,
"/var/lib/nova/instances/4a03fea7-e966-48e4-80ac-aa138db67243/console.log" rw,
# for qemu guest agent channel
owner "/var/lib/libvirt/qemu/channel/target/domain-instance-00000008/**" rw,
/dev/vhost-net rw,
root at ubuntu-trusty-5773:/etc/apparmor.d/abstractions# dpkg -S libvirt-qemu
libvirt-bin: /etc/apparmor.d/abstractions/libvirt-qemu
root at ubuntu-trusty-5773:/etc/apparmor.d/abstractions# dpkg -l libvirt-bin
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=========================================-=========================-=========================-=======================================================================================
ii libvirt-bin 1.3.1-1ubuntu10.6~cloud0 amd64 programs for the libvirt library
Seeing identical behavior on Xenial
ubuntu at ubuntu-xenial-5165:~$ dpkg -l libvirt-bin
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=========================================-=========================-=========================-=======================================================================================
ii libvirt-bin 1.3.1-1ubuntu10.8 amd64 programs for the libvirt library
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1665698/+subscriptions
More information about the Ubuntu-openstack-bugs
mailing list