← Back to team overview

group.of.nepali.translators team mailing list archive

[Bug 1644507] Re: [SRU] virt-aa-helper denied access to qcow2 backing file running nova in a snap

 

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

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

  * d/apparmor/usr.lib.libvirt.virt-aa-helper: Allow access to base
    images and snapshots stored in nova-hypervisor snap's $SNAP_COMMON
    directory, enabling use of the libvirt deb from the nova-hypervisor
    snap (LP: #1644507).

 -- Corey Bryant <corey.bryant@xxxxxxxxxxxxx>  Thu, 22 Jun 2017 14:43:11
-0400

** Changed in: libvirt (Ubuntu Xenial)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1644507

Title:
  [SRU] virt-aa-helper denied access to qcow2 backing file running nova
  in a snap

Status in libvirt package in Ubuntu:
  Fix Released
Status in libvirt source package in Xenial:
  Fix Released
Status in libvirt source package in Zesty:
  Fix Released
Status in libvirt source package in Artful:
  Fix Released

Bug description:
  [Impact]
  The apparmor profile for virt-aa-helper allows access to qcow2 backing images in some well know locations for OpenStack Nova:

    /var/lib/nova/images/** r,
    /var/lib/nova/instances/_base/** r,
    /var/lib/nova/instances/snapshots/** r,

  which is great when openstack is installed using deb's from the
  archive; I'm working on a snap for a Nova hypervisor, and the base
  images are stored in:

    /var/snap/nova-hypervisor/common/instances/_base

  so instances fail to boot as the generated profile for the instance
  does not contain access to the backing file as virt-aa-helper is
  DENIED access to it:

  [ 5144.554120] audit: type=1400 audit(1479983132.426:49771):
  apparmor="DENIED" operation="open" profile="libvirt-d140e3d0-071d-
  453f-99f2-a777fd1a1c3d" name="/var/snap/nova-
  hypervisor/common/instances/_base/a9dd2a42f4d46f9d8a628643d9aede38924668e6"
  pid=663 comm="qemu-system-x86" requested_mask="r" denied_mask="r"
  fsuid=115 ouid=115

  switched virt-aa-helper into complain mode:

  [ 5531.325617] audit: type=1400 audit(1479983519.193:49776):
  apparmor="ALLOWED" operation="open" profile="/usr/lib/libvirt/virt-aa-
  helper" name="/var/snap/nova-
  hypervisor/common/instances/_base/a9dd2a42f4d46f9d8a628643d9aede38924668e6"
  pid=5509 comm="virt-aa-helper" requested_mask="r" denied_mask="r"
  fsuid=0 ouid=115

  and the instance booted successfully.

  The actual disk for the instance is covered by:

    /**/disk{,.*} r,

  unfortunately the base image does not have a nice general-izable path
  in the same way.

  We could do:

    /var/**/images/** r,
    /var/**/_base/** r,
    /var/**/snapshots/** r,

  which would capture other locations for the openstack instances path
  in the event that its not the default path for nova.

  [Testcase]

  Run snap-test from the following to deploy openstack from snaps:
  github.com/openstack-snaps/snap-test

  [Regression Potential]
  Minimal regression potential, as this augments the existing virt-aa-helper to allow a new path to be accessed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1644507/+subscriptions