classic snap does not run on live session

[fossfreedom]

I'm testing Ubuntu Budgie's classic snap called "ubuntu-budgie-welcome" which is available in the beta channel.

Ubuntu Budgie 18.04 daily ISO 25/02/2018

The snap works just fine on a normal install. However this classic snap fails on the Ubuntu Budgie live session. As snaps become more prevalent - snaps - including classic snaps should work on live sessions.

For Ubuntu Budgie, the classic snap is very important because it presents the user vital info about the distro and instructions on how to install.

Copying the .desktop launcher from the menu I see the following issue in a terminal:

ubuntu-budgie@ubuntu-budgie:~$ env BAMF_DESKTOP_FILE_HINT=/var/lib/snapd/desktop/applications/ubuntu-budgie-welcome_budgie-welcome.desktop /snap/bin/ubuntu-budgie-welcome.budgie-welcome %U
snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: snapd 2.31.1+18.04
ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3
Uname: Linux 4.15.0-10-generic x86_64
ApportVersion: 2.20.8-0ubuntu10
Architecture: amd64
CasperVersion: 1.388
CurrentDesktop: Budgie:GNOME
Date: Sun Feb 25 23:28:38 2018
LiveMediaBuild: Ubuntu-Budgie 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180225)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: snapd
UpgradeStatus: No upgrade log present (probably fresh install)

[Jamie Strandboge (jdstrand)]

The snap-confine profile is not loaded at the time ubuntu-budgie-welcome is launched. You should see a different error if you do:

$ sudo apparmor_parser -r /etc/apparmor.d/*snap-confine*

Once the profile is loaded, because Ubuntu now uses overlay instead of aufs, you are going to need a snapd with https://github.com/snapcore/snapd/pull/4714 applied.

[Dustin Krysak (bashfulrobot)]

Hi Jamie, If I read this right, that implies a newer version of snapd? Is this something that is making its way into the daily? Am I understanding this correctly?

[Jamie Strandboge (jdstrand)]

PR 4714 is not committed yet (it is approved). Once committed to trunk, I'll propose it for 2.32.

The fact that the policy isn't loaded is a separate problem, but a newer snapd with 4714 should address this because when the snapd unit starts, it will notice that the system is a livecd, add a little bit of policy to snap-confine and reload this policy into the kernel (thus sidestepping the fact that something didn't load the snap-confine policy in the first place).

[Dustin Krysak (bashfulrobot)]

Is this something that will make it in prior to 18.04 (I assume not)? I only ask as we may have to do a workaround where the DEB runs off of the ISO, but the seed for install is the snap package.

thank you for the additional info!

[Jamie Strandboge (jdstrand)]

It is planned for 18.04. If other bugs remain for running classic or strict snaps on livecd, they'll need to get fixed.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jamie Strandboge (jdstrand)]

I tested to see if the changes in https://github.com/snapcore/snapd/pull/4714 would address this bug. I did this by:

1. in a livecd, perform 'sudo aa-status'. This showed no apparmor profiles were loaded
2. install a deb with https://github.com/snapcore/snapd/pull/4714. The act of installing the deb runs apparmor_parser on the snap-confine profile, so to simulate a fresh boot, I then unloaded the profiles with: sudo apparmor_parser -R /etc/apparmor.d/*snap-confine* (and confirmed with aa-status they weren't loaded
3. sudo snap install hello-world
4. sudo aa-status (this showed the snap-confine profiles from the core snap were loaded, along with the hello-world profiles, but *not* the snap-confine profile from /etc/apparmor.d
5. ran hello-world:
$ hello-world
snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks

Therefore, https://github.com/snapcore/snapd/pull/4714 is *not* sufficient to fix this bug. Once I do:

$ sudo apparmor_parser -r /etc/apparmor.d/*snap-confine*

Then strict and classic mode snaps work.

[Jamie Strandboge (jdstrand)]

The problem is that the apparmor systemd unit (and the script it calls) exit if /rofs/etc/apparmor.d exists. This is correct in the general case. What needs to happen is either snapd loads them itself or the apparmor init scripts instead load just the snap-confine profiles.

[Jamie Strandboge (jdstrand)]

*sigh* my test case in https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1751667/comments/8 was flawed. With the PR, on a livecd the apparmor unit correctly doesn't load the policy. snapd starts at some point, notices it is on an overlay, adds the overlay snippet to /var/lib/snapd/apparmor/snap-confine and then loads all the /etc/apparmor.d/*snap-confine* profiles. So long as snapd starts before preinstalled snaps then all is fine.

[Michael Hudson-Doyle (mwhudson)]

On 2 March 2018 at 11:37, Jamie Strandboge <email address hidden> wrote:

So long as snapd starts before preinstalled snaps then all is fine.
>

Given that "preinstalled" snaps are merely seeded, there's nothing to be
worried about here :-)

[Jamie Strandboge (jdstrand)]

This is now merged in 2.32. Please see https://forum.snapcraft.io/t/confined-snaps-dont-work-on-live-images-due-to-apparmor-path-mapping/3767/9 if you want to check it out for yourself.

[Zygmunt Krynicki (zyga)]

Based on the discussion in this bug report I'm marking this as fix released.