running ubuntu-desktop-init as a confined snap

[d-loose]

In our current testing setup we've been running the init wizard directly as /snap/ubuntu-desktop-init/current/bin/ubuntu_init, circumventing the snap confinement.

In order to get it to run as a confined snap, some issues need to be solved:

• by default snapd expects a user's home directory to be in /home, however for the gnome-initial-setup user it's /run/gnome-initial-setup. A solution for this exists, but I don't know what that would need to look like in practice if we want to get this onto the iso.
• the existing xdg services can't access the necessary dbus API's unless corresponding snap interfaces are used (e.g. account_control for user creation).
• once the provd backend is ready to use, the previous point becomes obsolete and the only thing we need to access from the confined snap environment is the backend's unix socket (might need the system-files snapd interface?).

Edit: We also need read access to

• the configuration file in /etc, /usr/local/share or /usr/share
• external image assets (flavors, oem), undecided location
• EULA files (oem), undecided location

For the last two it might make sense to use a single "resources" directory

resources
├── EULA
│   ├── EULA_cs.html
│   ├── EULA_da.html
│   ├── EULA_de.html
│   ├── EULA_el.html
│   ├── EULA_en.html
├── images
│   ├── accessibility.svg
│   ├── mascot.svg
...

[sergio-costas]

So running (as root) sudo snap set system homedirs=/run before launching the init snap, should be enough to allow it to run...

[sergio-costas]

About the DBus APIs, I think that a new snap interface would be needed, where we can add all the required access (for example, access to the gdm DBus API to launch the new session).

[sergio-costas]

This last interface should be superprivileged, of course.

[d-loose]

About the DBus APIs, I think that a new snap interface would be needed, where we can add all the required access (for example, access to the gdm DBus API to launch the new session).

Thanks, very good point - since the GDM service remains in the UI, we'd definitely need a snapd interface to access GDM's DBus API. Not sure how tricky this is, as OpenSession returns the address to a unix socket that we then need to access as well.

[sergio-costas]

Oh, you are right... we need to see where that unix socket is created, and also in that snap interface give full access to any unix socket in that folder...

[d-loose]

So running (as root) sudo snap set system homedirs=/run before launching the init snap, should be enough to allow it to run...

I've tried this and it seems to work if the snap is installed in devmode. However I get the following error when running it as a confined snap:

/user.slice/user-121.slice/session-c2.scope is not a snap cgroup

[d-loose]

Some updates on this:

• Most of the services have been outsourced to provd by now (GDM and telemetry aren't completely done yet)
• I've added plugs to the snapcraft.yaml that allow access to the provd socket, the config directory and the log directory

Also, I'm now able to circumvent the cgroup issue by pointing Exec in /usr/share/applications/gnome-initial-setup.desktop to the following launcher script:

#!/bin/bash
env DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus" /snap/bin/ubuntu-desktop-init

For reasons I don't understand, using that line directly in Exec doesn't work :shrug:

For reference: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1951491

[d-loose]

The final remaining service that needs to be migrated is Sysmetrics (not to be confused with the TelemetryService used in bootstrap). If we manage to implement the corresponding endpoint in provd, merging #582 should be the final step towards a working, fully-confined snap. Otherwise, we'll need to re-add the following plugs to the snapcraft.yaml:

• hardware-observe
• log-observe
• system-observe

@matthew-hagemann FYI