Hi Simon, thank you for your report as always! You reported this against Trusty - I'd expect so, but do you happen to know right away if this affects Xenial and Zesty as well?
AFAIK these rules are added by "add_file_path" depending on the flag as r or rw. This is iterated by virDomainDiskDefForeachPath and all found there are added. That code itself is a unification helper from former "everybody does it by himself" which is in since 0.8 - so very very long time. 2010-07-19 Daniel P. Berrange <[email protected]> »···Convert all disk backing store loops to shared helper API »···Update the QEMU cgroups code, QEMU DAC security driver, SELinux »···and AppArmour security drivers over to use the shared helper API »···virDomainDiskDefForeachPath(). »···* src/qemu/qemu_driver.c, src/qemu/qemu_security_dac.c, »··· src/security/security_selinux.c, src/security/virt-aa-helper.c: »··· Convert over to use virDomainDiskDefForeachPath() 2010-07-19 Daniel P. Berrange <[email protected]> »···Add an API for iterating over disk paths »···There is duplicated code which iterates over disk backing stores »···performing some action. Provide a convenient helper for doing »···this to eliminate duplication & risk of mistakes with disk format »···probing »···* src/conf/domain_conf.c, src/conf/domain_conf.h, »··· src/libvirt_private.syms: Add virDomainDiskDefForeachPath() Never the less, since this is just calling this helper and adds a rule for each I wonder if it just means the helper as upstream has a bug. virt-aa-helper even calls it with ignoreOpenFailure, which should not- ignore those with open issues (e.g. on some dynamically created block devices like nbd). The definition reads as if it should work the way we expect it: /* Call iter(disk, name, depth, opaque) for each element of disk and * its backing chain in the pre-populated disk->src.backingStore. * ignoreOpenFailure determines whether to warn about a chain that * mentions a backing file without also having metadata on that * file. */ If your case is a case that proves an error in that maybe tracing the flow through virDomainDiskDefForeachPath in your setup would make a good upstream bug report? Not 100% sure yet, what do you think Simon? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1658198 Title: multi-level stacked qcow2 files are not properly handled in Apparmor To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1658198/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
