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

[ell1e]

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:

[tchx84]

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

[ell1e]

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]

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]

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]

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

Edit: for what it's worth, seems like the underlying symlink issue will be resolved in an upcoming release at least: GeorgesStavracas/flatpak@d05074c / flatpak/flatpak#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]

@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]

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.

[rusty-snake]

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]

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]

Related: flatpak/flatpak#5854