Some snaps may mess up the home folder and cause loss of data!

snap
1

Recently I had a bad experience with the VLC snap which caused my home folder to become messed up, data was moved from one storage volume to another and this malefic behaviour ended up in loss of data. Looking at my logs / journals I could se that this was caused by the VLC snap, so I started to investigate the issue and I found that this behaviour was not caused by VLC itself but instead it was more likely caused by the snap container / sandbox. Using a virtual machine I found that the issue is reproducible and the bug may affect (many) other snapā€™s and I hope that someone could look into this issue before someone else gets hit by this bug.

I have described both the issue and how to reproduce it in the VLC forum thread here: https://forum.videolan.org/viewtopic.php?f=13&t=167572

Thanks!

2

I had a quick look. FWIW, the snap sandbox isnā€™t the problem. It doesnā€™t do anything except for sandboxing the child process, and as such it will not move your files around. However, what IMO appears to be the source of the problem is KDE Frameworks 6 snap which the vlc snap uses to provide the runtime.

Specifically, I installed vlc snap from edge, which pulled in the dependencies:

$ snap list vlc kf6-core24
Name        Version                      Rev   Tracking       Publisher  Notes
kf6-core24  6.10.1-6.20.0-6.5.3-25.08.3  36    latest/stable  kdeāœ“       -
vlc         4.0.0-dev-37239-g012ad39687  4367  latest/edge    videolanāœ“  -

the vlc app in the snap is declared this way:

  15 ā”‚ apps:
  16 ā”‚   vlc:
  17 ā”‚     command: usr/bin/vlc-snap-wrapper.sh
  18 ā”‚     common-id: org.videolan.vlc
...
  46 ā”‚     command-chain:
  47 ā”‚     - snap/command-chain/gpu-2404-wrapper
  48 ā”‚     - snap/command-chain/desktop-launch

which invokes desktop-launch, provided by kf6-core24. Subsequently snap/command-chain/desktop-launch6 from kf6-core24 attempts to ā€˜updateā€™ user dirs for some reason. It does quite a bit:

# If needs XDG update and xdg-user-dirs-update exists in $PATH, run it
if [ "$needs_xdg_update" = true ] && command -v xdg-user-dirs-update >/dev/null; then
  xdg-user-dirs-update
  update_xdg_dirs_values
fi

# Create links for user-dirs.dirs
if [ "$needs_xdg_links" = true ]; then
  if [ "$HOME" != "$SNAP_REAL_HOME" ]; then
    for ((i = 0; i < ${#XDG_SPECIAL_DIRS_PATHS[@]}; i++)); do
      b="$(realpath "${XDG_SPECIAL_DIRS_PATHS[$i]}" --relative-to="$HOME" 2>/dev/null)"
      if [[ -n "$b" && "$b" != "." && -e "$SNAP_REAL_HOME/$b" ]]; then
        [ -d "$HOME/$b" ] && rmdir "$HOME/$b" 2> /dev/null
        [ ! -e "$HOME/$b" ] && ln -s "$SNAP_REAL_HOME/$b" "$HOME/$b"
      fi
    done
  fi
else
  # If we aren't creating new links, check if we have content saved in old locations and move it
  for ((i = 0; i < ${#XDG_SPECIAL_DIRS[@]}; i++)); do
    old="${XDG_SPECIAL_DIRS_INITIAL_PATHS[$i]}"
    new="${XDG_SPECIAL_DIRS_PATHS[$i]}"
    if [ -L "$old" ] && [ -d "$new" ] && [ "$(readlink "$old" 2>/dev/null)" != "$new" ] &&
         (is_subpath "$old" "$SNAP_USER_DATA" || is_subpath "$old" "$SNAP_USER_COMMON"); then
      mv -vn "$old"/* "$new"/ 2>/dev/null
    elif [ -d "$old" ] && [ -d "$new" ] && [ "$old" != "$new" ] &&
         (is_subpath "$old" "$SNAP_USER_DATA" || is_subpath "$old" "$SNAP_USER_COMMON"); then
      mv -vn "$old"/* "$new"/ 2>/dev/null
    fi
  done
fi

IDK why this is needed, but thereā€™s probably a good reason for it. I suppose this is ok and relevant to 99% of cases, except one like yours. Since the home interface is connected, the snap is allowed to access your real $HOME and mess things up.

The kf6-core26 snap is published directly by KDE. Unfortunately they do not list any contact points where you could report bugs or issues. I cannot tell whether the desktop-launch script is something they came up with, or perhaps something that snapcraft adds automatically.

@mr_cal do you know where the desktop-launch wrappers come from? or, do you how to reach out to the KDE folks who publish the snap?

edit: found a similar pattern in the gnome-46-2404 runtime snap in command-chain/desktop-launch script.

2 Likes
3

@scarlettmoore is in charge of KDE extension and snaps.

4

@mborzecki1 Thank you for looking into this, it looks alot like youā€™ve found the actual culprit! :slight_smile:

I see no legitimate reason for moving user-content around like this without consent, this should never happen. Also I find it quite unfair that this is pinned to the VLC snap in the logs/journals even though the VLC snap had nothing to do with it.

Access control in snaps is either all or nothing; The entire home folder or nothing in the home folder, everything in all removeable media or nothing from any removable media. The only way around this is to use bind mounts to grant access to specific directories and symbolic links to decline access to specific directories. The construct in ā€œdesktop-launchā€ silently overrules this by moving data into ā€œgranted accessā€ for other snaps even though this is unwanted by the user. Besides, the directory on my encrypted drive had ~300GiB of data and the available space in the home directory was about 120GiB, so 180GiB of personal data went => /dev/null because of this malicious construct.

I hope that this is going to be fixed before someone else gets hit by it. A workaround for now would be to modify ā€œ/etc/xdg/user-dirs.confā€ and change ā€œenabled=Trueā€ to ā€œenabled=Falseā€ which should prevent the validity check of XDG user-dirs on each login/boot. This could however yield other issues when apps try to access inexistent XDG directories, but rather that than the other mess.

5

Should be under https://invent.kde.org/neon/snap-packaging/snapcraft-desktop-integration and @TehAppKiller is correct, @sgmoore maintains them.

6

Hi. I borrowed al.ost everything in that script from gnome. Unfortunately I wonā€™t be able to even look at this until Friday.

2 Likes