Comment 10 for bug 1546674

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