This is a follow-up to #1580463. (Note: I am not an expert in snap or apparmor related things, please correct me in anything I say below, thank you ;-).)
Bug #1580463 dealt with a problem in snaps achieving a correct path for accessing IBus and has since been closed as fixed. Here, I describe a problem which is most probably related and appears when user caches are stored in non-standard locations (i.e., not in ~/.cache).
Background:
- IBus is an input method for graphical Desktops like GNOME, allowing easy keyboard input for some languages (like Asian languages).
- It is the standard input method on GNOME, which is the standard desktop environment in Ubuntu.
- When the user logs into the desktop session, the IBus interface is created and sockets stored in the user's cache directory, the default being ~/.cache/ibus/ and ~/.config/ibus/.
- Applications need access to these data to consume keyboard input.
Regarding snaps:
- Snaps are confined, meaning they have access to only the smallest possible subset of file paths – including strictly defined paths in the users's home directory.
- In the process of resolving #1580463, it has been ensured that snaps can safely access ~/.cache/ibus/, so they can consume keyboard input.
Issue at hand:
- There is a well-documented and perfectly valid way of moving a user's cache directory away from the default location:
- It is defined by the freedesktop.org specification (see https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html) which GNOME adheres to.
- That specifies that all applications shall expect user specific cache data to be located below $XDG_CACHE_HOME, where this environment variable shall default to ~/.cache if unset or empty.
- I here report that snaps currently do not follow this specification, causing them to *refuse any keyboard input when IBus is selected as input method and $XDG_CACHE_HOME is set*.
Typical use case:
- $XDG_CACHE_HOME is typically set to a local file path when the users' home directories are located on a network share.
- This is a typical setup for mid- to larger scale applications of Ubuntu, such as schools or universities.
- Meaning this will affect *a lot of users* at institutions using Ubuntu (but not the average home user).
Test case:
- Chromium snap in Ubuntu 20.04[.1]
- Upon upgrade from 18.04 LTS to 20.04 LTS, the chromium-browser deb package (unconfined) will forcefully be replaced by the (confined) chromium snap, which manifests above described problem.
Impact:
- Chromium (and presumably other snaps) stop accepting keyboard input after LTS upgrade to Ubuntu 20.04 when $XDG_CACHE_HOME is set.
This is a severe problem.
Steps to reproduce:
- Set $XDG_CACHE_HOME to a location different from ~/.cache, such as /tmp/<something> or /var/<something>. (Both are paths very likely be used by installs with network located homes. Note this must be done before the graphical session starts, like in the user's ~/.profile.)
- Log the user out from and in again to the graphical session.
- Confirm (from a terminal) that IBus data is now located below $XDG_CACHE_HOME/ibus/bus.
- (rm -r ~/snap/chromium/current/.config/ if you had formerly started the chromium snap)
- Start the chromium snap.
- Observe that *it refuses to read any keyboard input*.
Cross references:
- https:/
- https:/