Activity log for bug #1707400

Date Who What changed Old value New value Message
2017-07-29 13:46:46 Bob Pickett bug added bug
2017-07-29 13:50:09 Apport retracing service tags amd64 apparmor apport-package need-duplicate-check xenial amd64 apparmor apport-package xenial
2017-07-29 13:50:10 Apport retracing service bug added subscriber Crash bug triagers for Ubuntu packages
2017-07-31 19:19:21 Andreas Hasenack libvirt (Ubuntu): status New Incomplete
2017-07-31 19:49:12 Andreas Hasenack attachment added apt-install-libvirt-bin.txt https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1707400/+attachment/4924725/+files/apt-install-libvirt-bin.txt
2017-07-31 19:49:36 Andreas Hasenack attachment added dmesg.txt https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1707400/+attachment/4924726/+files/dmesg.txt
2017-07-31 19:50:02 Andreas Hasenack attachment added syslog https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1707400/+attachment/4924727/+files/syslog
2017-07-31 19:51:00 Andreas Hasenack attachment added trusty.usr.sbin.libvirtd https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1707400/+attachment/4924728/+files/trusty.usr.sbin.libvirtd
2017-07-31 19:51:21 Andreas Hasenack attachment added trusty.usr.lib.libvirt.virt-aa-helper https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1707400/+attachment/4924729/+files/trusty.usr.lib.libvirt.virt-aa-helper
2017-07-31 19:52:08 Andreas Hasenack attachment added usr.lib.libvirt.virt-aa-helper https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1707400/+attachment/4924730/+files/usr.lib.libvirt.virt-aa-helper
2017-07-31 19:52:27 Andreas Hasenack attachment added usr.sbin.libvirtd https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1707400/+attachment/4924746/+files/usr.sbin.libvirtd
2017-07-31 20:01:36 Andreas Hasenack libvirt (Ubuntu): status Incomplete Confirmed
2017-07-31 20:55:43 Andreas Hasenack bug watch added https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792426
2017-07-31 20:59:27 Andreas Hasenack tags amd64 apparmor apport-package xenial amd64 apparmor apport-package server-next xenial
2017-08-01 12:29:56 Andreas Hasenack bug added subscriber Andreas Hasenack
2017-08-01 12:34:06 Andreas Hasenack libvirt (Ubuntu): importance Undecided Medium
2017-08-01 14:34:59 Andreas Hasenack nominated for series Ubuntu Trusty
2017-08-01 14:34:59 Andreas Hasenack nominated for series Ubuntu Xenial
2017-08-01 14:37:44 Stefan Bader bug task added libvirt (Ubuntu Trusty)
2017-08-01 14:37:50 Stefan Bader bug task added libvirt (Ubuntu Xenial)
2017-08-01 21:07:56 Andreas Hasenack description I have no further information ProblemType: Package DistroRelease: Ubuntu 16.04 Package: libvirt-bin 1.3.1-1ubuntu10.11 ProcVersionSignature: Ubuntu 4.4.0-87.110-generic 4.4.73 Uname: Linux 4.4.0-87-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.10 Architecture: amd64 Date: Sat Jul 29 09:05:14 2017 ErrorMessage: subprocess installed post-installation script returned error exit status 1 InstallationDate: Installed on 2016-02-02 (542 days ago) InstallationMedia: Ubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64 (20150805) ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-87-generic root=UUID=fafa9702-ccf4-455b-a78f-638b44006bc1 ro quiet splash vt.handoff=7 SourcePackage: libvirt Title: package libvirt-bin 1.3.1-1ubuntu10.11 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) [Impact] * An explanation of the effects of the bug on users and * 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. [Test Case] * detailed instructions how to reproduce the bug * 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. [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] * 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
2017-08-01 21:08:26 Andreas Hasenack summary package libvirt-bin 1.3.1-1ubuntu10.11 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 libvirt-bin doesn't regenerate apparmor cache in postinst
2017-08-01 21:08:30 Andreas Hasenack libvirt (Ubuntu): status Confirmed Fix Released
2017-08-01 21:47:30 Andreas Hasenack description [Impact] * An explanation of the effects of the bug on users and * 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. [Test Case] * detailed instructions how to reproduce the bug * 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. [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] * 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 [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: 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] * 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.
2017-08-01 21:48:22 Andreas Hasenack description [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: 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] * 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. [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: 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 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 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.
2017-08-01 22:37:13 Andreas Hasenack description [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: 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 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 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. [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: 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 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 (here is a pastebin: http://pastebin.ubuntu.com/25222966/. It shows libvirt apparently restarting successfully at the end, but it didn't): - 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 generate caches. Crucial: at this time, the old libvirt-bin apparmor profiles are installed still. - 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 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.
2017-08-01 22:50:31 Andreas Hasenack description [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: 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 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 (here is a pastebin: http://pastebin.ubuntu.com/25222966/. It shows libvirt apparently restarting successfully at the end, but it didn't): - 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 generate caches. Crucial: at this time, the old libvirt-bin apparmor profiles are installed still. - 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 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. [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: 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 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 (here is a pastebin: http://pastebin.ubuntu.com/25222966/. It shows libvirt apparently restarting successfully at the end, but it didn't): - 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 generate caches. Crucial: at this time, the old libvirt-bin apparmor profiles are installed still. - 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 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] In a nutshell, this fix does introduce a change in behaviour. But it's a change that other packages have already adopted (just grep for apparmor_parser in /var/lib/dpkg/info/*.postinst), and shouldn't be user visible. I also believe it's a less surprising behaviour than what we currently have. I took the option of fixing one specific apparmor_parser call instead of introducing dh_apparmor in d/rules, which would have been a much bigger change, even though that's what we have in Yakkety and later. Cache corruption seems to be dealt with by the tool correctly, although I haven't experimented with it. The documentation says: """ The default behaviour of the parser is to check if a cached version of a profile exists and if it does it attempt (sic) to load it into the kernel. If that load is rejected, then the parser will attempt to rebuild the cache file, and load again. """ [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.
2017-08-01 22:50:58 Andreas Hasenack libvirt (Ubuntu Trusty): assignee Andreas Hasenack (ahasenack)
2017-08-01 22:50:59 Andreas Hasenack libvirt (Ubuntu Xenial): assignee Andreas Hasenack (ahasenack)
2017-08-01 22:51:03 Andreas Hasenack libvirt (Ubuntu Trusty): status New In Progress
2017-08-01 22:51:06 Andreas Hasenack libvirt (Ubuntu Xenial): status New In Progress
2017-08-01 22:51:34 Andreas Hasenack libvirt (Ubuntu Trusty): importance Undecided Low
2017-08-01 22:51:37 Andreas Hasenack libvirt (Ubuntu Xenial): importance Undecided Medium
2017-08-01 22:52:20 Andreas Hasenack description [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: 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 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 (here is a pastebin: http://pastebin.ubuntu.com/25222966/. It shows libvirt apparently restarting successfully at the end, but it didn't): - 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 generate caches. Crucial: at this time, the old libvirt-bin apparmor profiles are installed still. - 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 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] In a nutshell, this fix does introduce a change in behaviour. But it's a change that other packages have already adopted (just grep for apparmor_parser in /var/lib/dpkg/info/*.postinst), and shouldn't be user visible. I also believe it's a less surprising behaviour than what we currently have. I took the option of fixing one specific apparmor_parser call instead of introducing dh_apparmor in d/rules, which would have been a much bigger change, even though that's what we have in Yakkety and later. Cache corruption seems to be dealt with by the tool correctly, although I haven't experimented with it. The documentation says: """ The default behaviour of the parser is to check if a cached version of a profile exists and if it does it attempt (sic) to load it into the kernel. If that load is rejected, then the parser will attempt to rebuild the cache file, and load again. """ [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. [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 install --reinstall libvirt-bin 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 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 (here is a pastebin: http://pastebin.ubuntu.com/25222966/. It shows libvirt apparently restarting successfully at the end, but it didn't): - 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 generate caches. Crucial: at this time, the old libvirt-bin apparmor profiles are installed still. - 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 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] In a nutshell, this fix does introduce a change in behaviour. But it's a change that other packages have already adopted (just grep for apparmor_parser in /var/lib/dpkg/info/*.postinst), and shouldn't be user visible. I also believe it's a less surprising behaviour than what we currently have. I took the option of fixing one specific apparmor_parser call instead of introducing dh_apparmor in d/rules, which would have been a much bigger change, even though that's what we have in Yakkety and later. Cache corruption seems to be dealt with by the tool correctly, although I haven't experimented with it. The documentation says: """ The default behaviour of the parser is to check if a cached version of a profile exists and if it does it attempt (sic) to load it into the kernel. If that load is rejected, then the parser will attempt to rebuild the cache file, and load again. """ [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.
2017-08-01 22:55:29 Andreas Hasenack description [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 install --reinstall libvirt-bin 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 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 (here is a pastebin: http://pastebin.ubuntu.com/25222966/. It shows libvirt apparently restarting successfully at the end, but it didn't): - 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 generate caches. Crucial: at this time, the old libvirt-bin apparmor profiles are installed still. - 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 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] In a nutshell, this fix does introduce a change in behaviour. But it's a change that other packages have already adopted (just grep for apparmor_parser in /var/lib/dpkg/info/*.postinst), and shouldn't be user visible. I also believe it's a less surprising behaviour than what we currently have. I took the option of fixing one specific apparmor_parser call instead of introducing dh_apparmor in d/rules, which would have been a much bigger change, even though that's what we have in Yakkety and later. Cache corruption seems to be dealt with by the tool correctly, although I haven't experimented with it. The documentation says: """ The default behaviour of the parser is to check if a cached version of a profile exists and if it does it attempt (sic) to load it into the kernel. If that load is rejected, then the parser will attempt to rebuild the cache file, and load again. """ [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. [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 install --reinstall libvirt-bin 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 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 (here is a pastebin: http://pastebin.ubuntu.com/25222966/. It shows libvirt apparently restarting successfully at the end, but it didn't): - 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 generate caches. Crucial: at this time, the old libvirt-bin apparmor profiles are installed still. - 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 * verify that service status shows the servicce being down: - sudo service libvirt-bin status 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] In a nutshell, this fix does introduce a change in behaviour. But it's a change that other packages have already adopted (just grep for apparmor_parser in /var/lib/dpkg/info/*.postinst), and shouldn't be user visible. I also believe it's a less surprising behaviour than what we currently have. I took the option of fixing one specific apparmor_parser call instead of introducing dh_apparmor in d/rules, which would have been a much bigger change, even though that's what we have in Yakkety and later. Cache corruption seems to be dealt with by the tool correctly, although I haven't experimented with it. The documentation says: """ The default behaviour of the parser is to check if a cached version of a profile exists and if it does it attempt (sic) to load it into the kernel. If that load is rejected, then the parser will attempt to rebuild the cache file, and load again. """ [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.
2017-08-01 23:01:35 Launchpad Janitor merge proposal linked https://code.launchpad.net/~ahasenack/ubuntu/+source/libvirt/+git/libvirt/+merge/328425
2017-08-01 23:02:38 Launchpad Janitor merge proposal linked https://code.launchpad.net/~ahasenack/ubuntu/+source/libvirt/+git/libvirt/+merge/328426
2017-08-07 14:02:19 Andreas Hasenack bug added subscriber Ubuntu Stable Release Updates Team
2017-08-07 14:19:06 Nodøn bug added subscriber Aaron Bruelisauer
2017-08-07 16:10:43 Christian Boltz bug added subscriber Christian Boltz
2017-08-09 13:34:13 Robie Basak libvirt (Ubuntu Xenial): status In Progress Fix Committed
2017-08-09 13:34:17 Robie Basak bug added subscriber SRU Verification
2017-08-09 13:34:21 Robie Basak tags amd64 apparmor apport-package server-next xenial amd64 apparmor apport-package server-next verification-needed verification-needed-xenial xenial
2017-08-09 13:34:38 Robie Basak libvirt (Ubuntu Trusty): status In Progress Fix Committed
2017-08-09 13:34:43 Robie Basak tags amd64 apparmor apport-package server-next verification-needed verification-needed-xenial xenial amd64 apparmor apport-package server-next verification-needed verification-needed-trusty verification-needed-xenial xenial
2017-08-09 17:25:18 Christian Ehrhardt  tags amd64 apparmor apport-package server-next verification-needed verification-needed-trusty verification-needed-xenial xenial amd64 apparmor apport-package server-next verification-done verification-done-trusty verification-done-xenial xenial
2017-08-23 00:33:07 Launchpad Janitor libvirt (Ubuntu Trusty): status Fix Committed Fix Released
2017-08-23 00:33:16 Chris Halse Rogers removed subscriber Ubuntu Stable Release Updates Team
2017-08-23 00:33:43 Launchpad Janitor libvirt (Ubuntu Xenial): status Fix Committed Fix Released