Open d-loose opened 7 months ago
So running (as root) sudo snap set system homedirs=/run
before launching the init snap, should be enough to allow it to run...
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).
This last interface should be superprivileged, of course.
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.
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...
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
Some updates on this:
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
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:
@matthew-hagemann FYI
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:
/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.account_control
for user creation).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 thesystem-files
snapd interface?).Edit: We also need read access to
/etc
,/usr/local/share
or/usr/share
For the last two it might make sense to use a single "resources" directory