Comment 5 for bug 1661626

This is probably something for snapcraft-desktop-helpers and the gnome extension for Snapcraft. It is the desktop-launch script that currently symlinks ~/.config/dconf to the location the snap will look for it, so it wouldn't be much of a stretch to do the same for $XDG_RUNTIME_DIR/dconf too. The "gsettings" interface looks like it already grants the required AppArmor permissions, so I don't think there is anything strictly necessary to do on the snapd side.

Longer term, we probably want to deprecate the gsettings interface and stop snaps from talking to dconf all together. If you're using a new enough version of GLib in the sandbox and portal support is enabled (i.e. GTK_USE_PORTAL=1 set in environment), then the GSettings API will use store settings in a flat file "$XDG_CONFIG_HOME/glib-2.0/settings/keyfile". Change notification is handled via an inotify watch on that file, comparing new values with those stored in memory.

This means that (a) the confined app can't see settings belonging to other applications, and (b) that data will be managed together with other snap user data. For the few desktop wide GSettings used by GTK's Wayland backend (e.g. theme, fonts, etc), there is an xdg-desktop-portal interface giving read-only access. Access to the portal API is already granted by snapd's desktop interface.