Bug#932815: snapd: "snap remove" broken with AppArmor 2.13.2+
On Mon, 02 Mar 2020, Алексей Шилин wrote: > On Tue, 23 Jul 2019 14:09:52 -0500 Jamie Strandboge < > ja...@canonical.com> wrote: > > The 'core' snap is one such runtime that is on all systems with snaps > > installed and the 'core' snap contains 'snapd'. > > > > [...] > > > > Since snapd is not installed by default, apt-getting it and then > > installing a snap will pull in the latest core snap so in practice no > > new snaps users of Buster should be affected. > > This doesn't seem to always be the case: Since I wrote this, it has been confirmed that under certain circumstances reexec will not work correctly. What is happening is that snapd on the system is 2.37.4-1+b1, and that version knows how to re-exec into the core snap. acestreamplayer uses 'base: core18' and while snapd will pull down core18, it will not re-exec into it. If you 'snap install core', you can workaround this issue (as you mentioned). snapd needs an update so that it can pull down what it needs to reexec (newer releases know about the 'snapd' snap and will pull that down instead). I discussed this just now with the snapd team and they plan to update snapd to have a newer version. -- Jamie Strandboge | http://www.canonical.com
Bug#932815: snapd: "snap remove" broken with AppArmor 2.13.2+
On Tue, 23 Jul 2019 14:09:52 -0500 Jamie Strandboge < ja...@canonical.com> wrote: > The 'core' snap is one such runtime that is on all systems with snaps > installed and the 'core' snap contains 'snapd'. > > [...] > > Since snapd is not installed by default, apt-getting it and then > installing a snap will pull in the latest core snap so in practice no > new snaps users of Buster should be affected. This doesn't seem to always be the case: aleksej@debian-geary:~$ snap version snap2.37.4-1+b1 snapd 2.37.4-1+b1 series 16 debian 10 kernel 4.19.0-8-amd64 aleksej@debian-geary:~$ sudo snap install acestreamplayer 2020-03-02T18:10:57+03:00 INFO snap "acestreamplayer" has bad plugs or slots: audio-playback (unknown interface "audio-playback") acestreamplayer 3.1.49-snap2 from vasilisc (vs) installed aleksej@debian-geary:~$ snap list Name Version Rev Tracking Publisher Notes acestreamplayer 3.1.49-snap2 10stablevs - core18 20200124 1668 stablecanonical✓ base aleksej@debian-geary:~$ snap version snap2.37.4-1+b1 snapd 2.37.4-1+b1 series 16 debian 10 kernel 4.19.0-8-amd64 aleksej@debian-geary:~$ sudo snap remove acestreamplayer error: cannot perform the following tasks: - Remove security profile for snap "acestreamplayer" (10) (cannot setup apparmor for snap "acestreamplayer": cannot unload apparmor profile: exit status 2 apparmor_parser output: File snap-update-ns.acestreamplayer not found, skipping... File snap.acestreamplayer.acestreamplayer not found, skipping... File snap.acestreamplayer.engine not found, skipping... File snap.acestreamplayer.mpv not found, skipping... ) - Remove security profile for snap "acestreamplayer" (10) (cannot unload apparmor profile: exit status 2 apparmor_parser output: File snap-update-ns.acestreamplayer not found, skipping... File snap.acestreamplayer.acestreamplayer not found, skipping... File snap.acestreamplayer.engine not found, skipping... File snap.acestreamplayer.mpv not found, skipping... ) aleksej@debian-geary:~$ I had to install 'core' explicitly (after finding this bug report).
Bug#932815: snapd: "snap remove" broken with AppArmor 2.13.2+
Hi, thanks a lot, Jamie, for all these explanations! Jamie Strandboge: > You may find it acceptable to remove the Breaks in > apparmor in Debian due to the above since the corner case is unlikely > and a simple 'sudo snap refresh' is a viable workaround if bugs come in. I'll do that for the moment and I'll let the snapd maintainers decide how they want to handle this problem in Buster and testing/sid. Cheers, -- intrigeri
Bug#932815: snapd: "snap remove" broken with AppArmor 2.13.2+
On Tue, 23 Jul 2019, intrig...@debian.org wrote: > Package: snapd > Version: 2.37.4-1 > Severity: normal > X-Debbugs-Cc: Jamie Strandboge > > Hi, > > One of the Ubuntu maintainers for src:apparmor (Jamie, Cc'ed) has > recently added a "Breaks: snapd (<< 2.38~)" relationship for the > apparmor binary package, justified by the fact that in earlier > versions of snapd, "snap remove" is incompatible with the way AppArmor > maintains its compiled policy cache in /var/cache/apparmor since > 2.13.2. I blindly trust Jamie's reasoning so I've merged this change > in apparmor 2.13.3-1. > > So we have two problems in Debian now: > > 1. Buster is presumably affected by the "snap remove" breakage > >Jamie: > > - Can you please shed some light on what's the exact problem > and user impact? With snapd < 2.38 and apparmor >= 2.13 (with the cache forest), then 'snap remove ' fails because snapd tries to remove the profiles and dies: $ snap version snap2.37.4-1+b1 snapd 2.37.4-1+b1 series 16 debian 10 kernel 4.19.0-5-amd64 $ sudo snap remove hello-world error: cannot perform the following tasks: - Remove security profile for snap "hello-world" (29) (cannot setup apparmor for snap "hello-world": cannot unload apparmor profile: exit status 2 ... > - Can easily point us to the fixes brought by snapd 2.38 > in this area? https://github.com/snapcore/snapd/pull/6549 > >I'd like to understand whether this is severe enough to warrant >fixing it in a Buster point-release, and whether the fix has >a chance to be accepted by the SRMs. snapd has a rather unique feature called 'reexec' that is enabled in Buster. In brief (and glossing over a few unimportant details), snaps run with a particular runtime. The 'core' snap is one such runtime that is on all systems with snaps installed and the 'core' snap contains 'snapd'. snapd is able to introspect the system and to reexec into the latest version. Therefore, while Buster has 2.37.4-1+b1, after the first 'snap refresh' (which happens multiple times per day in the background), the core snap will be refreshed and snapd will restart, using the one in the core snap. In this manner, Debian Buster systems will automatically update and then be ok: $ apt-cache policy snapd snapd: Installed: 2.37.4-1+b1 Candidate: 2.37.4-1+b1 Version table: *** 2.37.4-1+b1 500 500 http://ftp.us.debian.org/debian buster/main amd64 Packages 100 /var/lib/dpkg/status $ snap version snap2.39.3 snapd 2.39.3 series 16 debian 10 kernel 4.19.0-5-amd64 $ sudo snap remove hello-world hello-world removed Since snapd is not installed by default, apt-getting it and then installing a snap will pull in the latest core snap so in practice no new snaps users of Buster should be affected. Those who upgrade to Buster will more than likely have had networking enabled for the upgrade, which should've allowed for the core snap to refresh. The Breaks was introduced in apparmor because it does break snapd < 2.38 and to account for the time when snapd from the deb is the one in use and before the core snap is refreshed (which could be delayed due to network issues). You may find it acceptable to remove the Breaks in apparmor in Debian due to the above since the corner case is unlikely and a simple 'sudo snap refresh' is a viable workaround if bugs come in. > 2. apparmor >= 2.13.3-1 cannot migrate to testing as it breaks >co-installability with snapd > >This could be fixed by uploading snapd 2.38 or newer to sid. >Dear snapd maintainers, what are your plans in this respect? If the snapd maintainers are planning to update the deb (either by backporting the above patch or to a new version) you could adjust the Breaks as needed. -- Jamie Strandboge | http://www.canonical.com signature.asc Description: PGP signature
Bug#932815: snapd: "snap remove" broken with AppArmor 2.13.2+
Package: snapd Version: 2.37.4-1 Severity: normal X-Debbugs-Cc: Jamie Strandboge Hi, One of the Ubuntu maintainers for src:apparmor (Jamie, Cc'ed) has recently added a "Breaks: snapd (<< 2.38~)" relationship for the apparmor binary package, justified by the fact that in earlier versions of snapd, "snap remove" is incompatible with the way AppArmor maintains its compiled policy cache in /var/cache/apparmor since 2.13.2. I blindly trust Jamie's reasoning so I've merged this change in apparmor 2.13.3-1. So we have two problems in Debian now: 1. Buster is presumably affected by the "snap remove" breakage Jamie: - Can you please shed some light on what's the exact problem and user impact? - Can easily point us to the fixes brought by snapd 2.38 in this area? I'd like to understand whether this is severe enough to warrant fixing it in a Buster point-release, and whether the fix has a chance to be accepted by the SRMs. 2. apparmor >= 2.13.3-1 cannot migrate to testing as it breaks co-installability with snapd This could be fixed by uploading snapd 2.38 or newer to sid. Dear snapd maintainers, what are your plans in this respect? Cheers, -- intrigeri
