virt-aa-helper Apparmor profile missing rules for name resolution

Bug #1546674 reported by Simon Déziel on 2016-02-17
34
This bug affects 5 people
Affects Status Importance Assigned to Milestone
libvirt (Ubuntu)
High
Christian Ehrhardt 
Xenial
Medium
Christian Ehrhardt 

Bug Description

[Impact]

 * Apparmor denies several hostname related accesses by libvirt causing
   severe slowdowns in some cases.

[Test Case]

* Note: while there are various ways to trigger it - many have seen the
  issue, but often it is unclear when exactly it will trigger or does no
  more. So some of the repo-cases have proven to be unreliable - thanks
  Simon for this Repro howto listed here. (simplified as it turned out
  zvols are not needed according to comment #22)

1) Sync Xenial cloud-image
uvt-simplestreams-libvirt sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=xenial

2) Create a test guest with:
uvt-kvm create --memory 2048 --cpu 4 --password=ubuntu xenial-kernel-test release=xenial arch=amd64 label=daily

3) strop it and add an extra volume in a way like this snippet
   $ virsh shutdown xenial-kernel-test
   $ virsh edit xenial-kernel-test
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source file='/dev/sda4'/>
      <target dev='vdc' bus='virtio'/>
    </disk>

4) start the guest
virsh start xenial-kernel-test

6) check for apparmor denial messages
dmesg | tail | grep apparmor

Without the fix, Apparmor would report denials when accessing /etc/nsswitch.conf, /etc/host.conf, /etc/gai.conf, /run/resolvconf/resolv.conf and /dev/zdX (where X corresponds to the zvol number). Starting the guest should be much slower than usual.

With the fix in place no related Apparmor denials show up.

[Regression Potential]

 * The fix is rather small and "only" opens up apparmor confinement a bit.
   That makes us assume that the potential for regression should be
   minimal.

###############

Original description:

With libvirt-bin 1.3.1, starting a QEMU guest results in those AA denials:

Feb 17 12:06:23 simon-laptop kernel: [15734.513696] audit: type=1400 audit(1455728783.639:73): apparmor="DENIED" operation="open" profile="/usr/lib/libvirt/virt-aa-helper" name="/etc/nsswitch.conf" pid=23156 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Feb 17 12:06:23 simon-laptop kernel: [15734.513718] audit: type=1400 audit(1455728783.639:74): apparmor="DENIED" operation="open" profile="/usr/lib/libvirt/virt-aa-helper" name="/etc/host.conf" pid=23156 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Feb 17 12:06:23 simon-laptop kernel: [15734.513734] audit: type=1400 audit(1455728783.639:75): apparmor="DENIED" operation="open" profile="/usr/lib/libvirt/virt-aa-helper" name="/run/resolvconf/resolv.conf" pid=23156 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Feb 17 12:06:23 simon-laptop kernel: [15734.513885] audit: type=1400 audit(1455728783.639:76): apparmor="DENIED" operation="open" profile="/usr/lib/libvirt/virt-aa-helper" name="/run/resolvconf/resolv.conf" pid=23156 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

virt-aa-helper's AA profile hasn't changed recently so it seems like the helper is doing more in this release.

Additional information:

$ lsb_release -rd
Description: Ubuntu Xenial Xerus (development branch)
Release: 16.04

$ apt-cache policy apparmor libvirt-bin
apparmor:
  Installed: 2.10-3ubuntu1
  Candidate: 2.10-3ubuntu1
  Version table:
 *** 2.10-3ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
        100 /var/lib/dpkg/status
libvirt-bin:
  Installed: 1.3.1-1ubuntu1
  Candidate: 1.3.1-1ubuntu1
  Version table:
 *** 1.3.1-1ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: libvirt-bin 1.3.1-1ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-5.20-generic 4.4.1
Uname: Linux 4.4.0-5-generic x86_64
NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
ApportVersion: 2.20-0ubuntu3
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Feb 17 13:08:04 2016
KernLog:

SourcePackage: libvirt
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.libvirt.qemu.conf: [inaccessible: [Errno 13] Permission denied: '/etc/libvirt/qemu.conf']
modified.conffile..etc.libvirt.qemu.networks.default.xml: [deleted]

Simon Déziel (sdeziel) wrote :

Thanks I see that here too.

 status confirmed

Changed in libvirt (Ubuntu):
status: New → Confirmed
Changed in libvirt (Ubuntu):
importance: Undecided → High
Changed in libvirt (Ubuntu):
status: Confirmed → Triaged
Simon Déziel (sdeziel) wrote :

It seems that those Apparmor denials are responsible for severe slowdown of guests boot when the host boots up.

This simple fix makes the guests boot swiftly:

# diff -Naur /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper.orig /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper
--- /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper.orig 2016-08-14 10:32:27.051646248 -0400
+++ /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper 2016-08-14 10:32:20.019646323 -0400
@@ -66,4 +66,9 @@
   /**.vmdk r,
   /**.[iI][sS][oO] r,
   /**/disk{,.*} r,
+
+ # XXX: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1546674
+ /etc/hosts r,
+ /etc/host.conf r,
+ /etc/nsswitch.conf r,
 }

Robie Basak (racb) on 2016-08-16
tags: added: bitesize server-next
Stefan Bader (smb) on 2016-10-07
Changed in libvirt (Ubuntu Xenial):
importance: Undecided → Medium
status: New → Triaged
Stefan Bader (smb) wrote :

On a updated Xenial as well after a release upgrade to Yakkety, I was not able to see those messages for a VM created with uvtool. Serge, are you still able to confirm? Maybe this was settled somehow indirectly via abstractions/nameservice somehow. Though I failed to find when and how.

Simon Déziel (sdeziel) wrote :

My 3 updated Xenial machines are still affected by this. Since comment #3, I also added /etc/gai.conf so the new diff looks like this:

$ diff -Naur /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper{.orig,}
--- /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper.orig 2016-08-14 10:32:27.051646248 -0400
+++ /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper 2016-08-17 17:06:33.329358438 -0400
@@ -66,4 +66,10 @@
   /**.vmdk r,
   /**.[iI][sS][oO] r,
   /**/disk{,.*} r,
+
+ # XXX: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1546674
+ /etc/gai.conf r,
+ /etc/hosts r,
+ /etc/host.conf r,
+ /etc/nsswitch.conf r,
 }

I'm attaching a guest definition that triggers the bug hoping to help you reproduce it. If I can be of more help, please let me know.

Hi,
I was looking into reproducing this to be able to fix&verify then afterwards.
I don't see the messages either with my setup, but I 100% trust Simon to have a correct report.

It all is for name resolution and the profile change is only for read - so it will be safe.
We just need to able to reproduce.

So I just assume we have to find the bit of config triggering the issue (we will need repro steps for SRU anyway after all).

I'd have expected this to be due to libnss-libvirt (https://libvirt.org/nss.html) as it got added in yakkety. It would be the code that matches the denies.
But the reports are on Xenial so that can't be it.

I usually create my most basic test guests with:
uvt-simplestreams-libvirt sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=xenial
uvt-kvm create --memory 2048 --cpu 4 --password=ubuntu xenial-kernel-test release=xenial arch=amd64 label=daily

And as smb reports that doesn't trigger the issue.
@Simon could you create a guest with uvt as I shown above and check if that guest is free of the issue for you was well?
If yes - we have to compare the guest xml vs your usually used one.
If now - we have to check your local libvirt setup for what triggers this, so you might report any diff in libvirt.conf or (less likely) /etc/libvirt/qemu.conf that might be related then

Changed in libvirt (Ubuntu Xenial):
assignee: nobody → ChristianEhrhardt (paelzer)
Changed in libvirt (Ubuntu):
assignee: nobody → ChristianEhrhardt (paelzer)

At least in my instance, and based on at least one other reporter's
description, the issue manifests on upgrade of the host to Xenial with
existing guests. If you create new guests in Xenial or newer they may very
well be configured correctly (I really don't know). My interpretation was
that virt-aa-helper added some functionality in Xenial+ which requires this
access, but configs from older versions have not granted it. Or at least
maybe that would make repro easier?

Thanks Matt for your reply.
AFAIK that is what smb already tried in comment #4.

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.

Simon Déziel (sdeziel) 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.

Regards,
Simon

Simon Déziel (sdeziel) wrote :

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

Thanks Simon,
I found another one to trigger which is when failing to start a guest.
I can't reproduce with a working guest, but still it is a way to trigger - although it doesn't seem reliably.

Still I have a system to verify on for myself reporting e.g.
[85681.586318] audit: type=1400 audit(1476865131.741:189): apparmor="DENIED" operation="open" profile="/usr/lib/libvirt/virt-aa-helper" name="/etc/nsswitch.conf" pid=8448 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[85681.586329] audit: type=1400 audit(1476865131.741:190): apparmor="DENIED" operation="open" profile="/usr/lib/libvirt/virt-aa-helper" name="/etc/host.conf" pid=8448 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

I much more like your approach.

I'll prep something to test early next week (on a business trip the next days)

Hi,
unfortunately after a reboot of my host my local reproducibility is gone :-/

I don't know if you could, but would like to ask if one of you think you can verify that in Yakkety or Zesty.
The way the apparmor rules get created changed in >=Yakkety and since we have to start with the devel releases that is the place to go for the first verification.
Still Y&Z are widely the same, so I build for both in a ppa.

I build the suggested fix (along another one) in https://launchpad.net/~paelzer/+archive/ubuntu/libvirt-bug-1546674-1615550/+packages.
It would be great of one of you could test it there.

If none can please let me know so I know I have to try to recreate again somehow.

Simon Déziel (sdeziel) wrote :

On 2016-10-24 11:08 AM, ChristianEhrhardt wrote:
> Hi,
> unfortunately after a reboot of my host my local reproducibility is gone :-/

Strange, mine is reproducible 100% of the time, I'd like a self-fixing
bug too!

> I don't know if you could, but would like to ask if one of you think you can verify that in Yakkety or Zesty.
> The way the apparmor rules get created changed in >=Yakkety and since we have to start with the devel releases that is the place to go for the first verification.
> Still Y&Z are widely the same, so I build for both in a ppa.
>
> I build the suggested fix (along another one) in https://launchpad.net/~paelzer/+archive/ubuntu/libvirt-bug-1546674-1615550/+packages.
> It would be great of one of you could test it there.
>
> If none can please let me know so I know I have to try to recreate again
> somehow.

In 2 to 3 weeks I should be able to try to reproduce on Y or Z so if you
can reproduce before that, please be my guest! Thank again Christian.

Simon Déziel (sdeziel) wrote :

On 2016-10-24 11:08 AM, ChristianEhrhardt wrote:
> Hi,
> unfortunately after a reboot of my host my local reproducibility is gone :-/
>
> I don't know if you could, but would like to ask if one of you think you can verify that in Yakkety or Zesty.
> The way the apparmor rules get created changed in >=Yakkety and since we have to start with the devel releases that is the place to go for the first verification.
> Still Y&Z are widely the same, so I build for both in a ppa.
>
> I build the suggested fix (along another one) in https://launchpad.net/~paelzer/+archive/ubuntu/libvirt-bug-1546674-1615550/+packages.
> It would be great of one of you could test it there.

Thanks for providing this testing PPA. I was able to test the Yakkety
version of your package. With it, I get the following Apparmor messages
(also attached here):

apparmor="DENIED" operation="open"
profile="/usr/lib/libvirt/virt-aa-helper" name="/dev/zd0" pid=3357
comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
apparmor="DENIED" operation="open" profile="libvirt-UUID"
name="/proc/3374/task/3391/comm" pid=3374 comm="qemu-system-x86"
requested_mask="wr" denied_mask="wr" fsuid=111 ouid=111
...
apparmor="DENIED" operation="open" profile="libvirt-UUID"
name="/proc/3374/task/3414/comm" pid=3413 comm="qemu-system-x86"
requested_mask="wr" denied_mask="wr" fsuid=111 ouid=111

So while the /dev/zd0 denial was expected, the /proc/$pid/task/$pid/comm
ones were not. To address those, I applied the patch attached.

The attachment "aa-libvirt-qemu.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch

>
> So while the /dev/zd0 denial was expected, the /proc/$pid/task/$pid/comm
> ones were not.

Oh those where expected by me, I just would have hoped they are gone now -
see bug 1615550
But I see you found it already.

> To address those, I applied the patch attached.

Yeah I didn't realize in my quick patch that it doesn't only read but
actually rewrite the comm for the debug threads feature.
I also like your owner and pid check - which makes it more secure but still
allowing the needed access.
I think I need an apparmor training :-);
Thanks for your help!

I updated the ppa and it should now also got rid of these apparmor messages
while keeping your hosts fix in place.
Please if possible retest with that one.

I also think once we have confirmed that these both fixes help I'm gonna
submit them upstream.
They don't have to stay a Ubuntu delta forever.
Since you did most IMHO please let me know if you want to do that.

Simon Déziel (sdeziel) wrote :

On 2016-10-27 02:31 AM, ChristianEhrhardt wrote:
> I updated the ppa and it should now also got rid of these apparmor messages
> while keeping your hosts fix in place.
> Please if possible retest with that one.

2.1.0-1ubuntu10~ppa3 works well, the only denial is the one for /dev/zd0
[*]. I appreciate the quick turnaround, thanks.

> I also think once we have confirmed that these both fixes help I'm gonna
> submit them upstream.
> They don't have to stay a Ubuntu delta forever.
> Since you did most IMHO please let me know if you want to do that.

The Ubuntu delta seems pretty big already. I feel that most of it should
be sent upstream. I'll give it a try.

In the meantime, I'll be available for SRU testing.

*: zvols make good storage backends and virt-aa-helper be aware of them.
I'll open a wishlist bug for this.

On Thu, Oct 27, 2016 at 5:44 PM, Simon Déziel <email address hidden>
wrote:

>
> 2.1.0-1ubuntu10~ppa3 works well, the only denial is the one for /dev/zd0
> [*]. I appreciate the quick turnaround, thanks.

I can only return the thanks for a quick turnover.
Thanks for verifying the ppa.
To confirm - does that also confirm that the issues of bug 1615550
(/proc/$pid/task/*/comm) are gone as intended?

The Ubuntu delta seems pretty big already. I feel that most of it should
> be sent upstream. I'll give it a try.
>

Yes, thank you a lot for up-streaming.
In the meantime I marked you as Author on the two patches and Changelog to
properly credit all your work on that.

> In the meantime, I'll be available for SRU testing.
>

I'm waiting for a confirmation on a third apparmor related bug to make an
upload and SRUs from there.
I will notify you here once there is a Zesty or SRU version available for
verification.

Simon Déziel (sdeziel) wrote :

On 2016-11-03 06:01 AM, ChristianEhrhardt wrote:
> To confirm - does that also confirm that the issues of bug 1615550
> (/proc/$pid/task/*/comm) are gone as intended?

Yes, LP: #1615550 is fixed as well.

> The Ubuntu delta seems pretty big already. I feel that most of it should
>> be sent upstream. I'll give it a try.
>>
>
> Yes, thank you a lot for up-streaming.
> In the meantime I marked you as Author on the two patches and Changelog to
> properly credit all your work on that.

I appreciate it, thanks.

Changed in libvirt (Ubuntu):
status: Triaged → In Progress

FYI - Fix pushed to Zesty

@Simon could you give some extra detail on "severe slowdown" as we need it for the SRU template then. And since we lack a clear "steps to reproduce" maybe those as well if you happened to find the important bit to trigger it in the meantime.

What worked last week doesn't have to this week - I ran into an FTBFS - please wait a bit until resolved.

Simon Déziel (sdeziel) on 2016-11-14
description: updated
description: updated
Simon Déziel (sdeziel) on 2016-11-14
description: updated
Simon Déziel (sdeziel) wrote :

It's not specific to zvols after all as I just setup a new hypervisor where I hand out host's partitions to the guests like this:

    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source file='/dev/sda4'/>
      <target dev='vda' bus='virtio'/>
    </disk>

This is enough to get virt-aa-helper to try reading /etc/nsswitch.conf, /etc/host.conf and /etc/gai.conf.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libvirt - 2.1.0-1ubuntu13

---------------
libvirt (2.1.0-1ubuntu13) zesty; urgency=medium

  * drop d/p/ubuntu/fix-ftbfs-for-gnutls-3-5-6.patch as the offending change
    in gnutls has been reverted (LP: #1641615)
  * Build depend on gnutls >= 3.5.6-4ubuntu2 to build after the gnutls fix
    migrated

 -- Christian Ehrhardt <email address hidden> Thu, 17 Nov 2016 08:43:10 +0100

Changed in libvirt (Ubuntu):
status: In Progress → Fix Released
description: updated

Hi,
now that things are in the development release I could go on with this.

I simplified the reproduction steps according to comment #22 and wrote the SRU Template as required.

I prepared the SRU, tested it locally and uploaded for the SRU team to consider it - it just entered the queue waiting to be accepted - so waiting for the SRU Team to come by the queue next time.

Robie Basak (racb) wrote :

I think it's worth nothing that I think landing this SRU (I haven't verified the destination in the binary package) will cause a conffile prompt for any user who has modified usr.lib.libvirt.virt-aa-helper locally.

There is a comment with an explanation and an LP bug reference, which helps. Users who don't see the prompt won't be regressed whichever way the default answer falls. So in this case I think it's probably OK, but I would like an ack on this from another SRU team member please.

Thanks Robie,
it does indeed land in "/etc/apparmor.d/usr.lib.libvirt.virt-aa-helper" so that could happen.
I didn't think on that - thanks for catching this!

Yet I think the fix is worth it. And for those few that have the ability to manually modify this file it should be no huge challenge - as you outlined the comment and bug# will help.

I would expect that the non interactive default would be to keep whatever modifications they had in place (unless somebody updates with non default options). In the first case they won't regress (just don't get the fix) and in the second case (-o Dpkg::Options::="--force-confnew") they would have chosen so intentionally.

Waiting for an ack from another SRU Team member together with you ...

Martin Pitt (pitti) wrote :

Not much that we can do about the conffile prompt indeed. However, I disagree with the actual patch. This should include abstractions/nameservice instead, which allows these files plus a lot more for other name service methods. We really want to avoid having to SRU a conffile change twice, and this is *definitively* not sufficient for 16.10 and up (as you e. g. also need to be able to talk to resolved). Please also fix this in zesty. Thanks!

Changed in libvirt (Ubuntu):
status: Fix Released → In Progress

Thanks Martin for your extra insight into apparmor, working on a fresh fix for Zesty now.
Coming back to an SRU once that is tested and migrated.

I'd drop the Ubuntu Review Team subscription til then.

Hi Simon,
I've created a ppa with the modified fix as suggested by Martin.
They work just as good as the former fix, but staying more future proof by using the abstractions.
=> https://launchpad.net/~paelzer/+archive/ubuntu/libvirt-bug-1546674-1615550
I know you are usually only on LTS, but do you think you could take a look at that before I upload?

P.S. I've used one ppa for this and bug 1641618 trying to save you some work on those checks.

Simon Déziel (sdeziel) wrote :

Hello Christian,

On 2016-11-24 03:44 AM, ChristianEhrhardt wrote:
> I've created a ppa with the modified fix as suggested by Martin.

I was not sure that pulling such a big abstraction was needed but in
retrospective, Martin's suggestion makes sense. Why is virt-aa-helper
trying to do name resolution is still unclear to me though.

> They work just as good as the former fix, but staying more future proof by using the abstractions.
> => https://launchpad.net/~paelzer/+archive/ubuntu/libvirt-bug-1546674-1615550
> I know you are usually only on LTS, but do you think you could take a look at that before I upload?

FYI, I manually applied your 2 patches on Xenial and it addresses the 2
bugs.

> P.S. I've used one ppa for this and bug 1641618 trying to save you some
> work on those checks.

I appreciate it, I'll get back to you with Zesty testing as soon as
possible.

Thanks

Simon Déziel (sdeziel) wrote :

Christian, I'm happy to report that this LP is fixed in Zesty.

Thanks Simon for the confirmation.

Yet FYI I'll reroll the zesty fix to become equal to the one Pitti suggested for the SRU.
I only want to avoid a proliferation of updates and therefore want to group that with some other things which are stalled just a bit. Should be ready to go in 5-10 days and an SRU to Xenial from there as well.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libvirt - 2.1.0-1ubuntu14

---------------
libvirt (2.1.0-1ubuntu14) zesty; urgency=medium

  * d/p/u/apparmor-fix-name-resolution.patch rework the fix to base
    on the apparmor nameservice abstraction to be future proof (LP: #1546674).
  * d/p/ubuntu/apparmor-fix-new-devicetypes.patch add new block device types to
    virt-aa-helpers profile (LP: #1641618)
  * d/p/u/apparmor-fix-other-seclabels.patch refresh to the now upstream
    accepted solution (LP: #1633207).

 -- Christian Ehrhardt <email address hidden> Thu, 24 Nov 2016 08:06:38 +0100

Changed in libvirt (Ubuntu):
status: In Progress → Fix Released

Reworked fix in Zesty and working, refreshed the SRU upload which is ready and waiting for SRU review now.

Hello Simon, or anyone else affected,

Accepted libvirt into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libvirt/1.3.1-1ubuntu10.6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in libvirt (Ubuntu Xenial):
status: Triaged → Fix Committed
tags: added: verification-needed
Simon Déziel (sdeziel) on 2016-12-12
tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libvirt - 1.3.1-1ubuntu10.6

---------------
libvirt (1.3.1-1ubuntu10.6) xenial; urgency=medium

  * d/apparmor/usr.lib.libvirt.virt-aa-helper: add missing rules for name
    resolution to virt-aa-helper Apparmor profile (LP: #1546674).

 -- Christian Ehrhardt <email address hidden> Tue, 22 Nov 2016 09:39:18 +0100

Changed in libvirt (Ubuntu Xenial):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for libvirt has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers