Sorry, I mixed up `.cache` and `.config` in the bug description (corrected).
I originally found this problem referring to the users CACHE directory. But as ibus needs both, .cache and .config, it is to be expected that the same problem appears when users' CONFIG is relocated (wich is as easily possible as CACHE). The relevant environment variables from the freedesktop specification are (see https://specifications.freedesktop.org/basedir- spec/latest/ar01s03.html): - $XDG_CACHE_HOME (defaults to ~/.cache) - $XDG_CONFIG_HOME (defaults to ~/.config) Both must be taken care of, as there are valid reasons for setting them to non-standard locations, esp. in networking environments. ** Description changed: 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 config directory, the default being ~/.config/ibus/bus/ . - - Applications need access to this data to consume keyboard input. + - 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 ~/.config/ibus/bus/, so they can consume keyboard input. + - 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 config directory away from the default location: + - 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 configuration data to be located below $XDG_CONFIG_HOME, where this environment variable shall default to ~/.config 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_CONFIG_HOME is set*. + - 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_CONFIG_HOME is typically set to a local file path when the users' home directories are located on a network share. + - $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_CONFIG_HOME is set. + - 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_CONFIG_HOME to a location different from ~/.config, 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.) + - 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_CONFIG_HOME/ibus/bus. + - 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*. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1890905 Title: Snaps cannot access IBus when $XDG_CACHE_HOME is set To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1890905/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
