On 2016-10-18 12:32 PM, Simon Deziel wrote: > Thanks Christian, I'll give uvtool a try. > > On 2016-10-18 11:56 AM, ChristianEhrhardt wrote: >> Thanks Matt for your reply. >> AFAIK that is what smb already tried in comment #4. > > My hosts were fresh installs but the guests xml were carried from an > older version. > >> Never the less I checked the upgrade path once more. >> With a modified conffile (just an empty line, but to not get the new one as >> in the bug report here) >> And with an old guest created on Xenial. >> It was not triggering the apparmor denies. >> >> https://launchpadlibrarian.net/288736150/apt.xml also didn't hold a lot >> of differences to my guests that would help me to trigger the issue. >> >> That said - I still look out to understand what bit of config triggers that >> accesses - as a valid repro is usually recommended for the SRU. >> In the worst case, we have luck to have you and Simon being able to verify - >> but I usually at least try to be able to reproduce. > > I also have a colleague that is affected by the same issue. > > FYI, I also get denials related to the zvol: > > [Tue Oct 18 12:25:29 2016] audit: type=1400 audit(1476807929.293:265): > apparmor="DENIED" operation="open" > profile="/usr/lib/libvirt/virt-aa-helper" name="/dev/zd128" pid=5432 > comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > [Tue Oct 18 12:25:29 2016] audit: type=1400 audit(1476807929.293:266): > apparmor="DENIED" operation="open" > profile="/usr/lib/libvirt/virt-aa-helper" name="/etc/nsswitch.conf" > pid=5432 comm="virt-aa-helper" requested_mask="r" denied_mask="r" > fsuid=0 ouid=0 > [Tue Oct 18 12:25:29 2016] audit: type=1400 audit(1476807929.293:267): > apparmor="DENIED" operation="open" > profile="/usr/lib/libvirt/virt-aa-helper" name="/etc/host.conf" pid=5432 > comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 > > The zvol read access seems to be entirely optional but maybe it's what's > causing the NSS stuff? Anyway, I'll try to convert the uvtool qcow2 to a > zvol to make sure. I'll report with my findings.
So the zvol seems to be the smoking gun. Here is what I did after creating the xenial-kernel-test guest using Christian's instruction for uvtool: # Create a zvol zfs create -V 8G zlxd/xenial-kernel-test # Copy the qcow2 data to the zvol qemu-img convert -O raw \ /var/lib/uvtool/libvirt/images/xenial-kernel-test.qcow \ /dev/zvol/zlxd/xenial-kernel-test # Update the guest definition to use the zvol <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='none'/> <source file='/dev/zvol/zlxd/xenial-kernel-test'/> <target dev='vda' bus='virtio'/> </disk> # boot the guest virsh start xenial-kernel-test # check for apparmor denial messages dmesg | tail | grep apparmor Regards, Simon -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1546674 Title: virt-aa-helper Apparmor profile missing rules for name resolution To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1546674/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs