On Tue, 23 Jul 2019, [email protected] wrote: > Package: snapd > Version: 2.37.4-1 > Severity: normal > X-Debbugs-Cc: Jamie Strandboge <[email protected]> > > 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 <name>' fails because snapd tries to remove the profiles and dies: $ snap version snap 2.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 snap 2.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
