Where does the Flatpak store its configs?

[firefoxlover]

Please agree to the following

• I have searched existing issues for duplicates
• I agree to follow this project's Code of Conduct

Summary

The Cryptomator Flatpak doesn't seem to store its configs inside the Flatpak Container

Motivation

Flatpaks should store their data in ~/.var/app/org.cryptomator.Cryptomator instead of some random directory.

I tried to restrict Cryptomators filesystem Access, but it doesnt save the passwords and locations in KWallet.

~/.local/share/Cryptomator/mnt: rw
~/.local/share: create
# directory of the encrypted folder: rw
# what is missing to save the state?

Considered Alternatives

Keeping the filesystem access completely unrestricted, not an option.

Anything else?

using Fedora 39 with KDE Plasma

[purejava]

This issue belongs to https://github.com/flathub/org.cryptomator.Cryptomator/issues.

You are right: Cryptomator does not store its config inside the Flatpak container:
https://github.com/flathub/org.cryptomator.Cryptomator/blob/97a93b068f7f7c20c2bbef50930e1fd058405eca/org.cryptomator.Cryptomator.yaml#L126

Flatpak recommends doing so: "Retaining and sharing configuration with non-Flatpak installations is to be avoided.", but does not enforce that.

Nevertheless, my personal opinion is, that it's better as Cryptomator does it, as this offers the opportunity to use different Cryptomator clients. You e.g. create a vault with the Flatpak app and because the configuration is available, you can continue using it with the AppImage or a version installed from a repository.

[infeo]

Nevertheless, my personal opinion is, that it's better as Cryptomator does it, as this offers the opportunity to use different Cryptomator clients. You e.g. create a vault with the Flatpak app and because the configuration is available, you can continue using it with the AppImage or a version installed from a repository.

I follow this argument. Especially, since if flatpak is affected by a bug, the user can still switch to the AppImage without setting up the vaults again.

[firefoxlover]

okay, thanks for pointing me to the right file. I would create a PR defining exactly those directories as permissions, this would allow Cryptomator to be easily restricted in terms of storage access, if a user knows where their vault is.

xdg-home/.config/Cryptomator
xdg-home/.local/share/Cryptomator #not sure how to reference home here

# problem is those directories need to be created, requiring access to the entire directory and all other apps directories
xdg-config
xdg-share

There is no permission to just create a directory, which means at least this access is completely unrestricted.

https://docs.flatpak.org/en/latest/sandbox-permissions-reference.html#filesystem-permissions

Would still be cool to add those last two directories as flatpak permissions, maybe even the first two.

Then a user could first create those directories (by launching the app) and after that restrict the permission again, so the app will not have access to other apps configs.

I dont really see the importance of your argumentation, because users shouldnt need to switch to an Appimage or whatever, as the Flatpak works well.

The --persist=path option can be used to map paths from the user’s home directory into the sandbox filesystem. This makes it possible to avoid configuring access to the entire home directory, and can be useful for applications that hardcode file paths in ~/.

This is also interesting and may be used instead. This sounds like the appcode can stay untouched and those directories could be emulated.

If the flatpak should break, users could still extract these configs from ~/.var/app/org.cryptomator.Cryptomator/.