desktop: fix fonts access

[sergio-costas]

Inside /etc/fonts/conf.avail are several soft links to files at /usr/share/fontconfig. Although AppArmour rules are in place to allow access to that folder to snaps that have the desktop plug connected, the folder itself isn't being mounted inside the container, thus it isn't accessible from inside.

This patch adds that folder to the list of font folders, to ensure that it is available from inside a container.

Fix https://bugs.launchpad.net/snapd/+bug/2017313

[alexmurray]

LGTM.

[jhenstridge]

I am unsure about whether this is worth doing. Most desktop snaps won't be using the config under /etc/fonts, as the desktop-launch script does:

export FONTCONFIG_PATH="$SNAP_DESKTOP_RUNTIME/etc/fonts"
export FONTCONFIG_FILE="$SNAP_DESKTOP_RUNTIME/etc/fonts/fonts.conf"

So they're oblivious to whether the symlinks in /etc/fonts/conf.d are dangling. We haven't been using the system font configuration in a long time, as there is no guarantee that it will be compatible with the libfontconfig inside the sandbox.

The library's configuration parser has poor forward compatibility, as it will reject configurations with unknown elements/attributes. This last showed up when config files started adding <its:rules> elements that weren't supported by older libfontconfigs.

It's been a while since the last config language update, but encouraging snaps to use the system configuration just sets us up to repeat those problems should it change again.

[sergio-costas]

@jhenstridge That's a good point... so then it's better to encourage snap groups to include any font that they would need, like in the case of Steam.

[sergiocazzolato]

@sergio-costas as I see you could close this pr. Thanks for your help digging on this problem.

[sergio-costas]

@sergiocazzolato Ops... sorry, I completely forgot about this. Closing.