| 2020-08-08 15:38:06 |
Rüdiger Kupper |
bug |
|
|
added bug |
| 2020-08-08 15:38:59 |
Rüdiger Kupper |
description |
This is a follow-up to #1580463. (Note: I am not an expert in snap or apparmor related things, please correct my 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 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*. |
This is a follow-up to #1580463. (Note: I am not an expert in snap or apparmor related things, please correct my 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*. |
|
| 2020-08-08 15:39:12 |
Rüdiger Kupper |
description |
This is a follow-up to #1580463. (Note: I am not an expert in snap or apparmor related things, please correct my 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*. |
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*. |
|
| 2020-08-08 15:41:29 |
Rüdiger Kupper |
description |
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*. |
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*. |
|
| 2020-08-08 16:04:45 |
Rüdiger Kupper |
description |
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*. |
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*. |
|
| 2020-08-08 16:05:35 |
Rüdiger Kupper |
description |
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*. |
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 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*. |
|
| 2020-08-08 16:08:48 |
Rüdiger Kupper |
description |
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 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*. |
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*. |
|
| 2020-08-08 16:10:23 |
Rüdiger Kupper |
description |
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*. |
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 ~/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*. |
|
| 2020-08-08 16:17:33 |
Rüdiger Kupper |
description |
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 ~/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*. |
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, such as /tmp/<anything> or /var/<anything>. (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.
- (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*. |
|
| 2020-08-08 16:19:24 |
Rüdiger Kupper |
description |
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, such as /tmp/<anything> or /var/<anything>. (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.
- (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*. |
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, 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.
- (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*. |
|
| 2020-08-11 14:36:18 |
Rüdiger Kupper |
attachment added |
|
Log with XDG:CACHE_HOME unset (working) https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1890905/+attachment/5400722/+files/log-working |
|
| 2020-08-11 14:36:56 |
Rüdiger Kupper |
attachment added |
|
Log with XDG:CACHE_HOME set (not working) https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1890905/+attachment/5400723/+files/log-notworking2 |
|
| 2020-08-25 14:48:35 |
Olivier Tilloy |
bug |
|
|
added subscriber Olivier Tilloy |
| 2020-08-31 08:19:26 |
Samuele Pedroni |
snapd (Ubuntu): importance |
Undecided |
Medium |
|
| 2020-08-31 09:06:59 |
Rüdiger Kupper |
description |
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, 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.
- (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*. |
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*. |
|
| 2021-02-28 17:11:48 |
Launchpad Janitor |
snapd (Ubuntu): status |
New |
Confirmed |
|
| 2021-05-16 20:33:50 |
Gunnar Hjalmarsson |
bug |
|
|
added subscriber Gunnar Hjalmarsson |
| 2021-06-14 14:11:47 |
Gunnar Hjalmarsson |
bug |
|
|
added subscriber James Henstridge |
| 2023-05-24 07:26:34 |
Jan-Helge |
bug |
|
|
added subscriber Jan-Helge |
