interfaces/desktop: allow snaps to provide a desktop slot, granting access to system fonts and xdg-desktop-portal

[jhenstridge]

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-commenter]

Codecov Report

Merging #10753 (c88e64d) into master (1437ce2) will increase coverage by 0.00%. The diff coverage is 100.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

[mardy]

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?

[jhenstridge]

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".

[jhenstridge]

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.

[pedronis]

@jhenstridge this also needs a test re-run

[jhenstridge]

I've merged master to kick off another test run. I don't think any of the failures look related to my changes.