** 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. 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. Issue at hand: - There is a well-documented and perfectly valid way of moving a user's config 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*. + - $XDG_CONFIG_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. + + This is a severe problem. + + + Steps to reproduce: + - Set $XDG_CONFIG_HOME to a location different from ~/.config. (This must be done before the graphical session starts, like in the user's ~/.profile.) + - Log the user out from and out again to the graphical session. + - Confirm (from a terminal) that IBus data is now located below $XDG_CONFIG_HOME/ibus/bus. + - (rm -r ~/.config/snap/chromium if you had formerly started the chromium snap) + - Start the chromium snap. + - Observe that *it refuses to read any keyboard input*.
** 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. 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. Issue at hand: - There is a well-documented and perfectly valid way of moving a user's config 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*. - $XDG_CONFIG_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. This is a severe problem. - Steps to reproduce: - Set $XDG_CONFIG_HOME to a location different from ~/.config. (This must be done before the graphical session starts, like in the user's ~/.profile.) - - Log the user out from and out again to the graphical session. + - 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. - (rm -r ~/.config/snap/chromium if you had formerly started the chromium snap) - Start the chromium snap. - Observe that *it refuses to read any keyboard input*. ** 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. 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. Issue at hand: - There is a well-documented and perfectly valid way of moving a user's config 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*. + + 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. - 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. This is a severe problem. Steps to reproduce: - Set $XDG_CONFIG_HOME to a location different from ~/.config. (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. - (rm -r ~/.config/snap/chromium if you had formerly started the chromium snap) - Start the chromium snap. - Observe that *it refuses to read any keyboard input*. ** 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. 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. Issue at hand: - There is a well-documented and perfectly valid way of moving a user's config 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*. 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. - 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. This is a severe problem. Steps to reproduce: - Set $XDG_CONFIG_HOME to a location different from ~/.config. (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. - - (rm -r ~/.config/snap/chromium if you had formerly started the chromium snap) + - (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 [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
