tchx84 / Flatseal

Manage Flatpak permissions
GNU General Public License v3.0
1.14k stars 68 forks source link

After removing folder from flatseal file access list, symlink error persists on startup #702

Open ell1e opened 2 months ago

ell1e commented 2 months ago

It seems like I can't add symlink and its target to files accessible to app, such that the app sees both the symlink as a symlink targeting a path and also sees the target path as a regular folder inside its sandbox. Instead I'm getting a weird error that seems to claim that the target isn't a symlink when it is:

Screenshot_20240623_104310

tchx84 commented 2 months ago

@ell1e just a flyby comment; you can't add multiple directories that way. Add each directory/file in a separate entry

ell1e commented 2 months ago

Thanks for the help! The UI text above seemed to suggest to me that is possible. Maybe that could use some fine-tuning then, unless it's just me - but I feel like it's not necessarily obvious the comma means I need to make separate entries.

I fixed it now and used multiple entries. Sadly, the error remains the same. It seems like the handling of symlinks is somehow broken.

ell1e commented 1 month ago

I'm starting to think this is a security problem, because this error still shows when I remove all file access on the host system. Seems like the access isn't removed after all, which seems like a potentially data escape issue. Is there some situation where the flatseal config may silently fail to apply?

rusty-snake commented 1 month ago

It seems like I can't add symlink and its target to files accessible to app, such that the app sees both the symlink as a symlink targeting a path and also sees the target path as a regular folder inside its sandbox.

Known flatpak/bwrap limitation inherited from the old Linux mount API.

ell1e commented 1 month ago

Okay, but this seems like a scary situation that it still touches any files on disk after I changed flatseal settings to this:

Screenshot_20240708_092717

Edit: for what it's worth, seems like the underlying symlink issue will be resolved in an upcoming release at least: https://github.com/GeorgesStavracas/flatpak/commit/d05074ce9117005b22cd0cdf07d85ed992c52b99 / https://github.com/flatpak/flatpak/issues/3477 so that's cool. But I don't understand why it's still trying to do something with symlinks after I deleted all these settings.

tchx84 commented 1 month ago

@ell1e flatseal-wise you should:

  1. Check the override files under ~/.local/share/flatpak/overrides/<APP_ID and ~/.local/share/flatpak/overrides/global (in case you accidentally added something globally).
  2. Run $ flatpak ps, and $ flatpak kill <APP_ID>, to make sure the app really did stop.

Beyond that, if the error still shows up, then you might still have some left over files in $HOME after one of your experiments. Lastly, you can also try $ rm -rf ~/.var/app/<APP_ID>, to kind-of remove/reset any remaining application data.

ell1e commented 1 month ago

Thanks so much for your help! It does seem that the app-specific file contains the override, see below. I'm just wondering, is that really intended if the settings no longer contain that path? I'm just wondering how that ended up in that file, and whether when the user supposedly disables all filesystem access in flatseal whether that should show up as a warning somewhere in the UI. Screenshot_20240708_130545

rusty-snake commented 1 month ago

The manifest of io.github.sharkwouter.Minigalaxy contains filesystems=~/GOG Games:create; (flatpak info -m io.github.sharkwouter.Minigalaxy). In order to remove this permission, flatseal need to create a negative permission filesystems=!~/GOG Games (note the exclamation mark).

<End facts, begin speculation> flatpak seems to interpret this not only as 'do not grant filesystems=~/GOG Games (i.e. remove it in memory) but as a revoke access from it by mouning a tmpfs over it (like it would do when you have filesystems=home;!~/GOG Games.

ell1e commented 1 month ago

I feel like the expected behavior would be that flatseal doesn't somehow remove this manifest-induced permission by default, but rather just show it in the UI so I can see and edit it. Or alternatively, show it in some grayed out separate area that indicates even if I remove all manual filesystem permissions, this one stays in place, with maybe some info on how to remove it outside of flatseal.

Sorry if for some reasons that's a nonsensical suggestion though, it's just my gut feeling as a user.

rusty-snake commented 1 month ago

Related: https://github.com/flatpak/flatpak/issues/5854