Slack snap rev 250 (4.50.136): "Permission denied" writing ~/.cache & ~/.config on XFCE — regression from rev 224

Summary

After the auto-refresh from rev 224 → 250 (channel latest/stable, 4.50.136), Slack fails to start on an XFCE session. It tries to write to the real ~/.cache and ~/.config, which the home interface denies by design, so it aborts before opening a window. Rev 224 worked fine on the same machine.

Environment

  • Ubuntu 26.04, snapd 2.75.2+ubuntu26.04.2, kernel 7.0.6
  • Desktop: XFCE / Xubuntu (X11)
  • slack rev 250, 4.50.136, latest/stable, home interface connected

Error output

mkdir: cannot create directory '/home/USER/.cache/slack-snap': Permission denied
/snap/slack/250/bin/electron-launch: line 40: /home/USER/.cache/slack-snap/loaders.cache: No such file or directory
Couldn't save to /home/USER/.config/chromium/local-settings.json: EACCES: permission denied,
  open '/home/USER/.config/chromium/local-settings.json.XXXXXXXXXX'
[...]/process_singleton_posix.cc:347] Failed to create /home/USER/.config/chromium/SingletonLock: Permission denied (13)
Aborted (core dumped) slack

Root cause

The home interface intentionally excludes top-level dot-dirs — from the generated profile (/var/lib/snapd/apparmor/profiles/snap.slack.slack):

owner @{HOME}/[^s.]**  rwklix,

so ~/.cache and ~/.config are never writable through home. Confined apps are expected to write under their private ~/snap/slack/<rev>/ home instead.

Rev 250 rewrote bin/electron-launch so it no longer normalizes HOME and honors the session’s XDG_CACHE_HOME / XDG_CONFIG_HOME:

# Do not override HOME — it breaks Mesa/GBM library resolution inside the snap.
...
CACHE_DIR="${XDG_CACHE_HOME:-$HOME/.cache}/slack-snap"

On XFCE, /etc/xdg/xfce4/xinitrc exports XDG_CACHE_HOME=$HOME/.cache and XDG_CONFIG_HOME=$HOME/.config (the real paths) into the session/activation environment. Those leak into the snap, so cache/config now resolve outside the snap’s private home → AppArmor DENIED. Pre-250 builds effectively sidestepped this; rev 250 no longer does.

This will hit any environment that exports XDG_CACHE_HOME/XDG_CONFIG_HOME (XFCE/Xubuntu by default, plus custom setups), so it’s not machine-specific.

Reproduction

  1. XFCE/Xubuntu session (confirm echo $XDG_CACHE_HOME/home/USER/.cache).
  2. snap install slack (rev 250) and run slack.
  3. Observe the Permission denied errors above; Slack aborts.

Confirmed inside confinement:

$ snap run --shell slack -c 'mkdir -p "$XDG_CACHE_HOME/slack-snap"'
mkdir: cannot create directory '/home/USER/.cache/slack-snap': Permission denied
# vs. the snap's private home, which is allowed:
$ snap run --shell slack -c 'mkdir -p "$HOME/.cache/slack-snap" && echo OK'
OK

Suggested fix

In bin/electron-launch, reset XDG_CACHE_HOME/XDG_CONFIG_HOME to the snap’s private home (e.g. $SNAP_USER_DATA/.cache / .config) before launching — or unset them — instead of inheriting the session values. That restores pre-250 behavior without re-introducing the Mesa/GBM HOME-override regression the comment refers to.

Workarounds (for affected users)

  • Launch with the leaked vars stripped: env -u XDG_CACHE_HOME -u XDG_CONFIG_HOME slack (wrap /snap/bin/slack in ~/.local/bin/slack and/or the .desktop Exec= line).
  • Pin to the last good revision: sudo snap refresh slack --revision=224 --amend && sudo snap refresh --hold slack.

Possibly related: Slack snap stopped working after Ubuntu updates (#51066, Slack snap stopped working after ubuntu updates) — a separate rev-250-era regression (GNOME-schema segfault); flagging in case both trace back to the same packaging refresh.