** Description changed:
[Impact]
+ TL;DR
+ libvirt-bin stops working after a release upgrade from Trusty to Xenial.
Other scenarios possible.
- * An explanation of the effects of the bug on users and
+ Workaround after it breaks:
+ sudo touch /etc/apparmor.d/{usr.lib.libvirt.virt-aa-helper,usr.sbin.libvirtd}
+ sudo apt -f install
- * justification for backporting the fix to the stable release.
- * In addition, it is helpful, but not required, to include an
- explanation of how the upload fixes this bug.
+ The libvirt-bin package in Trusty and Xenial reloads the apparmor profile in
postinst, but without taking into account possible apparmor caches. It uses
this call:
+
+ apparmor_parser -r <profile> || true
+
+ instead of what dh_apparmor and every other package is using nowadays,
+ and is also recommended in the apparmor_parser manpage:
+
+ apparmor_parser -r -T -W <profile> || true
+
+ Where:
+ -T: skip reading the cache
+ -W: write out the cache
+
+ The apparmor_parser(8) manpage has this to say about how the apparmor
+ cache is considered:
+
+ """
+ By default, if a profile's cache is found in the location specified by
--cache-loc and the timestamp is newer than the profile, it will be loaded from
the cache.
+ """
+
+ That is reasonable behaviour. After all, the cache is generated from the
+ profile file. If someone wants to change the profile, it will be edited
+ and thus have a more recent timestamp than the cache.
+
+ Furthermore, since the libvirt-bin packages in Trusty and Xenial do not
+ specify -W, that is, they do not write out a cache file, then using just
+ "-r" to load a profile is consistent.
+
+ But if something outside the libvirt-bin package decides to generate
+ apparmor caches, then we might have a problem.
+
+ One such scenario is an Ubuntu release upgrade from Trusty to Xenial. Here is
what was observed during such an upgrade:
+ - new libvirt-bin is unpacked
+ - new apparmor is unpacked
+ - new apparmor is set up. This sets up new abstractions, and also generates
an apparmor cache for all profiles. This is new behaviour: the trusty apparmor
package does not do this. Crucial: this is still using the old libvirt-bin
apparmor profiles
+ - new libvirt-bin is setup. This installs the new apparmor profile for this
version of libvirt-bin. Crucial: the profile timestamp is not $(now), but
whatever timestamp the file has inside the debian package. Which is *older*
than the cache generated above
+ - libvirt-bin reloads the apparmor profile with -r. apparmor picks the cached
profile because its timestamp is newer than the profile
+ - libvirt-bin fails to start
+
+ The fix is to call apparmor_parser with -T and -W in postinst. That will
+ always invalidate the apparmor cache and generate a new one based on the
+ current contents of the profile file.
+
+ Another fix would be do use dh_apparmor to install the two profiles
+ libvirt-bin uses. In fact, debian/rules even have those calls, but they
+ are commented. We believe that doing that is a more invasive fix, and
+ that just adding the -T and -W options to the existing apparmor_parser
+ call has the same effect and is less invasive, being more in the spirit
+ of an SRU to an LTS release.
+
+ In Yakkety and Zesty, dh_apparmor is used, but the call with just "-r"
+ remains in postinst. That was only removed in artful, where we finally
+ only rely on dh_apparmor for this.
[Test Case]
- * detailed instructions how to reproduce the bug
+ * install libvirt-bin
+ * check it's working. This command should work and return an empty list of
virtual machines:
+ - sudo virsh list
+ * break the apparmor profile /etc/apparmor.d/usr.sbin.libvirtd by editing it
and commenting the line "network inet stream," like this:
+ #network inet stream,
+ * generate a cache file for it:
+ - sudo apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.libvirtd
+ * purge libvirt-bin:
+ - sudo apt purge libvirt-bin
+ * install libvirt-bin back. It will fail to start the service:
+ - sudo apt install libvirt-bin
+ * verify that virsh list fails to connect to libvirt:
+ - sudo virsh list
- * these should allow someone who is not familiar with the affected
- package to reproduce the bug and verify that the updated package fixes
- the problem.
+ If you repeat that last step with the fixed package, either after having
+ encountered the error, or by running all steps again and skipping
+ installing the broken package, the service will start correctly.
+
[Regression Potential]
- * discussion of how regressions are most likely to manifest as a result
+ * discussion of how regressions are most likely to manifest as a result
of this change.
- * It is assumed that any SRU candidate patch is well-tested before
- upload and has a low overall risk of regression, but it's important
- to make the effort to think about what ''could'' happen in the
- event of a regression.
+ * It is assumed that any SRU candidate patch is well-tested before
+ upload and has a low overall risk of regression, but it's important
+ to make the effort to think about what ''could'' happen in the
+ event of a regression.
- * This both shows the SRU team that the risks have been considered,
- and provides guidance to testers in regression-testing the SRU.
+ * This both shows the SRU team that the risks have been considered,
+ and provides guidance to testers in regression-testing the SRU.
[Other Info]
-
- * Anything else you think is useful to include
- * Anticipate questions from users, SRU, +1 maintenance, security teams and
the Technical Board
- * and address these questions in advance
+ This bug affects Trusty too, but we haven't had a report about it yet. The
only case so far is this release upgrade to Xenial.
+
+ Only administrators using Trusty who for one reason or another decide to
+ use apparmor caches for libvirt *could* be affected, depending on the
+ sequence of events. The test case shows such a possible scenario.
+
+ Since the change is simple, I included it for Trusty as well and will
+ leave it up to the SRU team to decide if it's worth fixing there or not.
+ I would perfectly understand if it is deemed not worthy for Trusty at
+ this time.
** Description changed:
[Impact]
TL;DR
libvirt-bin stops working after a release upgrade from Trusty to Xenial.
Other scenarios possible.
Workaround after it breaks:
sudo touch /etc/apparmor.d/{usr.lib.libvirt.virt-aa-helper,usr.sbin.libvirtd}
sudo apt -f install
-
- The libvirt-bin package in Trusty and Xenial reloads the apparmor profile in
postinst, but without taking into account possible apparmor caches. It uses
this call:
+ The libvirt-bin package in Trusty and Xenial reloads the apparmor
+ profile in postinst, but without taking into account possible apparmor
+ caches. It uses this call:
apparmor_parser -r <profile> || true
instead of what dh_apparmor and every other package is using nowadays,
and is also recommended in the apparmor_parser manpage:
apparmor_parser -r -T -W <profile> || true
Where:
- -T: skip reading the cache
+ -T: skip reading any existing cache
-W: write out the cache
The apparmor_parser(8) manpage has this to say about how the apparmor
cache is considered:
"""
By default, if a profile's cache is found in the location specified by
--cache-loc and the timestamp is newer than the profile, it will be loaded from
the cache.
"""
That is reasonable behaviour. After all, the cache is generated from the
profile file. If someone wants to change the profile, it will be edited
and thus have a more recent timestamp than the cache.
Furthermore, since the libvirt-bin packages in Trusty and Xenial do not
specify -W, that is, they do not write out a cache file, then using just
"-r" to load a profile is consistent.
But if something outside the libvirt-bin package decides to generate
apparmor caches, then we might have a problem.
One such scenario is an Ubuntu release upgrade from Trusty to Xenial. Here is
what was observed during such an upgrade:
- new libvirt-bin is unpacked
- new apparmor is unpacked
- new apparmor is set up. This sets up new abstractions, and also generates
an apparmor cache for all profiles. This is new behaviour: the trusty apparmor
package does not do this. Crucial: this is still using the old libvirt-bin
apparmor profiles
- new libvirt-bin is setup. This installs the new apparmor profile for this
version of libvirt-bin. Crucial: the profile timestamp is not $(now), but
whatever timestamp the file has inside the debian package. Which is *older*
than the cache generated above
- libvirt-bin reloads the apparmor profile with -r. apparmor picks the cached
profile because its timestamp is newer than the profile
- libvirt-bin fails to start
The fix is to call apparmor_parser with -T and -W in postinst. That will
always invalidate the apparmor cache and generate a new one based on the
current contents of the profile file.
Another fix would be do use dh_apparmor to install the two profiles
libvirt-bin uses. In fact, debian/rules even have those calls, but they
are commented. We believe that doing that is a more invasive fix, and
that just adding the -T and -W options to the existing apparmor_parser
call has the same effect and is less invasive, being more in the spirit
of an SRU to an LTS release.
In Yakkety and Zesty, dh_apparmor is used, but the call with just "-r"
remains in postinst. That was only removed in artful, where we finally
only rely on dh_apparmor for this.
[Test Case]
- * install libvirt-bin
- * check it's working. This command should work and return an empty list of
virtual machines:
- - sudo virsh list
- * break the apparmor profile /etc/apparmor.d/usr.sbin.libvirtd by editing it
and commenting the line "network inet stream," like this:
- #network inet stream,
- * generate a cache file for it:
- - sudo apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.libvirtd
- * purge libvirt-bin:
- - sudo apt purge libvirt-bin
- * install libvirt-bin back. It will fail to start the service:
- - sudo apt install libvirt-bin
- * verify that virsh list fails to connect to libvirt:
- - sudo virsh list
+ * install libvirt-bin
+ * check it's working. This command should work and return an empty list of
virtual machines:
+ - sudo virsh list
+ * break the apparmor profile /etc/apparmor.d/usr.sbin.libvirtd by editing it
and commenting the line "network inet stream," like this:
+ #network inet stream,
+ * generate a cache file for it:
+ - sudo apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.libvirtd
+ * purge libvirt-bin:
+ - sudo apt purge libvirt-bin
+ * install libvirt-bin back. It will fail to start the service:
+ - sudo apt install libvirt-bin
+ * verify that virsh list fails to connect to libvirt:
+ - sudo virsh list
If you repeat that last step with the fixed package, either after having
encountered the error, or by running all steps again and skipping
installing the broken package, the service will start correctly.
-
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result
of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
This bug affects Trusty too, but we haven't had a report about it yet. The
only case so far is this release upgrade to Xenial.
Only administrators using Trusty who for one reason or another decide to
use apparmor caches for libvirt *could* be affected, depending on the
sequence of events. The test case shows such a possible scenario.
Since the change is simple, I included it for Trusty as well and will
leave it up to the SRU team to decide if it's worth fixing there or not.
I would perfectly understand if it is deemed not worthy for Trusty at
this time.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1707400
Title:
libvirt-bin doesn't regenerate apparmor cache in postinst
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1707400/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
