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.
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.
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. /launchpadlibra rian.net/ 288736150/ apt.xml also didn't hold a lot
> 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:/
> 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(147680792 9.293:265) : "/usr/lib/ libvirt/ virt-aa- helper" name="/dev/zd128" pid=5432 aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 9.293:266) : "/usr/lib/ libvirt/ virt-aa- helper" name="/ etc/nsswitch. conf" aa-helper" requested_mask="r" denied_mask="r" 9.293:267) : "/usr/lib/ libvirt/ virt-aa- helper" name="/ etc/host. conf" pid=5432 aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
apparmor="DENIED" operation="open"
profile=
comm="virt-
[Tue Oct 18 12:25:29 2016] audit: type=1400 audit(147680792
apparmor="DENIED" operation="open"
profile=
pid=5432 comm="virt-
fsuid=0 ouid=0
[Tue Oct 18 12:25:29 2016] audit: type=1400 audit(147680792
apparmor="DENIED" operation="open"
profile=
comm="virt-
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.
Regards,
Simon