snapd
snapd copied to clipboard
interfaces/desktop: allow snaps to provide a desktop slot, granting access to system fonts and xdg-desktop-portal
This is a resubmission of #10609, with some additions.
At present, the only slot implementation for the desktop interface is an implicit slot on classic systems. In order to use GUI snaps on Ubuntu Core Desktop, we need something else to provide the slot. At the moment, our plan has been to have the ubuntu-desktop-session
snap provide the slot, as it is already running many of the services this interface grants access to.
This PR is not a complete implementation of that idea, but starts by allowing application snaps to provide the slot and to provide access to host system fonts in this form.
As with the implicit slot on classic systems, this is bind mounting in font directories from the host system mount namespace. On a standard Ubuntu Core system, this will bind mount a number of empty directories into the plug-side snap's mount namespace as it doesn't ship any fonts. On the Ubuntu Core Desktop prototype, we do have a selection of fonts available in the boot base snap though.
Ideally we'd instead be mounting from the fonts we know are visible to the slot-side snap. In practice, that would mean mounting from the slot snap's base snap. This seems like it'd be a bit fragile though, since the AppArmor and mount rules for the plug snap won't be regenerated when the slot-side's base snap is upgraded.
Codecov Report
Merging #10753 (c88e64d) into master (1437ce2) will increase coverage by
0.00%
. The diff coverage is100.00%
.
:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@ Coverage Diff @@
## master #10753 +/- ##
=======================================
Coverage 78.85% 78.85%
=======================================
Files 1013 1013
Lines 125905 125908 +3
=======================================
+ Hits 99281 99288 +7
+ Misses 20425 20422 -3
+ Partials 6199 6198 -1
Flag | Coverage Δ | |
---|---|---|
unittests | 78.85% <100.00%> (+<0.01%) |
:arrow_up: |
Flags with carried forward coverage won't be shown. Click here to find out more.
Files Changed | Coverage Δ | |
---|---|---|
interfaces/builtin/desktop.go | 91.34% <100.00%> (+0.25%) |
:arrow_up: |
... and 3 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more
Looks good to me so far. :-)
Just to make sure I understood the plan: on core systems, we will have some snaps (tha base one, and maybe also others in the future?) which provide fonts. When such snaps are installed, bind mounts will be created for the individual font files to make them appear under the system's /user/share/fonts
. This directory is then recursively bind mounted into every snap using the desktop interface, so that the fonts will be accessible there too.
If the above is correct, then I don't understand you last remark about AppArmor: the apparmor rules for the plug snap will only need to grant access to /usr/share/fonts/
, so why will they need to be regenerated?
The scripts used to build the current Ubuntu Core Desktop prototype image can be found here:
https://github.com/canonical/ubuntu-core-desktop/
It differs from a regular Ubuntu Core device in that the boot file system comes from a core20-gdm
base snap rather than core20
. This base snap includes additional packages to enable the GDM login screen and the gnome-initial-setup user creation workflow. That effectively comprises a basic GNOME system.
The user session runs as a command exposed by the ubuntu-desktop-session
snap that is included by the model definition. That snap doesn't actually contain any binary code or fonts: instead it uses core20-gdm
as its base, and runs the binaries found there.
In it's current form, this PR works for the prototype image, because the base snap of ubuntu-desktop-session is the same as the boot base snap of the system as a whole. Ideally the set of fonts should depend on whatever snap provides the slot. But as I outlined this is a bit fragile if we wanted to use fonts from the "slot snap's base snap".
I've updated this PR adding the changes we needed to get xdg-desktop-portal working on core. The architecture looks something like this:
sequenceDiagram
participant A as app
participant U as unconfined
participant S as desktop-session
A->>U: call o.fd.portal.* API
U->>S: call o.fd.impl.portal.* backend to show UI
S->>U: response from UI
U->>A: respond to app
In this case, all the UI and desktop integration provided by gnome-shell, xdg-desktop-portal-gtk, and xdg-desktop-portal-gnome runs confined in the context of the desktop-session snap, with unconfined xdg-desktop-portal and xdg-document-portal acting as an intermediary to the app.
@jhenstridge this also needs a test re-run
I've merged master to kick off another test run. I don't think any of the failures look related to my changes.