Commit 12317957ecd6c37a2fb16275dcdeeacfe25c517 introduced an incompatible architectural change for the AppArmor security driver. Specifically, virSecurityManagerSetAllLabel() is now called much later in src/qemu/qemu_process.c:qemuProcessStart(). Previously, SetAllLabel() was called immediately after GenLabel() such that after the dynamic label (profile name) was generated, SetAllLabel() would be called to create and load the AppArmor profile into the kernel before qemuProcessHook() was executed. With 12317957ecd6c37a2fb16275dcdeeacfe25c517, qemuProcessHook() is now called before SetAllLabel(), such that aa_change_profile() ends up being called before the AppArmor profile is loaded into the kernel (via ProcessLabel() in qemuProcessHook()). This patch addresses the change by making GenLabel() load the AppArmor profile into the kernel after the label (profile name) is generated. SetAllLabel() is then adjusted to only reload_profile() and append stdin_fn to the profile when it is specified. This also makes the AppArmor driver work like its SELinux counterpart with regard to SetAllLabel() and stdin_fn. Passes its part of 'check' and 'syntax-check' (though libvirt_net_rpc_la-virnetmessage.lo failed to compile and po_check failed the syntax check for unrelated reasons). Prior to writing this patch, the issue was discussed on IRC with Daniel Berrange and Eric Blake. Other discussed alternatives were to do a 2 stage qemuProcessHook(), where ProcessLabel() was only called in the second stage after the handshake. In attempting this, it still didn't address the fact that aa_change_profile() was being called on an unloaded profile so it was abandoned. Another idea was to create a second private API call that the AppArmor driver would use to load the profile that would be a no-op for the SElinux driver. I started to go this route, but in the end it was both unneeded and too complicated once I realized I could simply load the profile in GenLabel() and still use SetAllLabel() to reload the profile when stdin_path was specified. The current fix is implemented wholly within the AppArmor driver and I think much cleaner. Reference: https://launchpad.net/bugs/795800 -- Jamie Strandboge | http://www.canonical.com