Hi Andreas, thanks for the ping. I think the regression risk of a backport is pretty low, but the last time I tried I wasn't able to actually reproduce the impact to the user (a QEMU crash), just the proximate cause (the /dev/tapXX device being removed from the apparmor profile). For an SRU I'd much prefer to be able to reproduce the actual impact to the user.
I need to go dig into QEMU a bit to understand when & how it might try to do some operation on that path; the problem is that libvirt passes macvtap devices as file descriptors, so I'm not really sure what kind of operation QEMU might be doing on a tapfd that would involve AppArmor mediation. If you have any pointers on that I'd love to hear them. If we can come up with a reproducer for the QEMU crash then I'd be happy to put together the rest of the SRU. I will try to get to a reproducer but its pretty far down my priority queue. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2126574 Title: Fix AppArmor policy restore for runtime rules (upstream #692) To manage notifications about this bug go to: https://bugs.launchpad.net/libvirt/+bug/2126574/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
