Bug #2008279 reappears (loss of keyboard input for x11 snaps) if ~/.cache is a symlink

[Bob]

Background:
Homedir sits on it's own mount point/disk drive. It died. Some dirs were restored manually and I took the opportunity to "move" my ~/.cache to the more "XDG friendly" dir ~/.config/.cache, then did a:

ln -s ~/.config/.cache ~/.cache

After that NO x11 based snap application would receive keyboard input and the error was exactly the same as Bug #2008279. Removing the link created above and moving the ~/.config/.cache back to ~/.cache solved the problem, keyboard input to all x11 based snaps started working again.

Environment:
Kubuntu Lunar 23.04
snapd 2.59.1+23.04ubuntu1.1
libglib2.0-0:amd64 2.76.1-1

To reproduce:
Logout of a "testuser" account.
Login as another user.
As user with proper permissions:
mv /home/testuser/.cache /home/testuser/.config/.cache
(confirm owner, group and perms are still correct for /home/testuser/.config/.cache)
ln -s /home/testuser/.config/.cache /home/testuser/.cache

Log back into the testuser account.
Start (for example) the Firefox snap app -> NO keyboard input will work
Try it with any other x11 based snap -> No keyboard input will work
Log out

Reverse the above, remove the link and move /home/testuser/.config/.cache back to /home/testuser/.cache.
Log back in

Start the firefox snap application again and keyboard input works.
Start any other x11 based snap application and keyboard now works.

Suspect that the ibus-portal socket can not be be communicated with correctly when .cache is a link since those sockets sit in the .cache directory tree.

[Alex Murray (alexmurray)]

The standard location for the XDG_CACHE_HOME directory is ~/.cache - and so snapd generates AppArmor rules which reference this path. AppArmor however resolves symlinks to their real path name, and so if ~/.cache is a symlink to ~/.config/cache then AppArmor will see the application try and access the file ~/.config/cache/xxx whereas the rule for AppArmor only allows ~/.cache/xxx - as such this is then denied.

Long story short is that it is not supported to have ~/.cache as a symlink - this needs to be a real directory.

[Bob (bob-cauthen)]

It would have been nice to have had some kind of check or warning or something/anything verifying this during runtime, other than the behavior seen, which required a fair amount of troubleshooting time to "fix".

But, regardless, thank you for confirming Alex.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.