Prefer portals first, then narrow paths, and use --filesystem=host only when the app cannot work otherwise. The Flatpak documentation advises limiting static access and preferring portals, because every static grant is access that a bug or a malicious dependency can use.
What each option gives
| Option | Access given | Trade off |
|---|---|---|
| Portal file chooser | The file the user picks | Least access, user driven |
| Narrow path such as xdg-download | One folder | Predictable, still static |
| Read only suffix | Same path, no writes | Cuts damage from a bug |
| home | The home directory except ~/.var/app | Wide |
| host | All top level paths except reserved ones, which includes home | Widest |
The documentation lists options like :ro for read only and :create, plus XDG shortcuts such as xdg-download and xdg-config. Some paths are reserved, such as /usr and /dev, and ~/.var/app requires explicit access.
A decision guide
- Does the app open or save files the user chooses? Use the file chooser portal. No static grant is needed. GTK3 and Qt5 support portals transparently, per the docs.
- Does it need one known folder? Grant that folder only, read only if it never writes.
- Does it need many folders, like an editor for a whole project tree? Consider whether a portal flow plus user selection is enough. If not, grant the smallest set of paths you can name.
- Is host the only way? Write down why, tell users in the app listing and revisit it each release.
Why this matters for supply chain risk
Your app includes dependencies you did not write. A compromised dependency runs with the app's permissions. If the app has host access, the dependency does too. Narrow permissions limit what a bad package can read or change, which makes permissions a supply chain control as well as a privacy one.
Testing a narrower manifest
Remove a permission, run the app, and note what breaks. The documentation suggests flatpak run --log-session-bus $FLATPAK_ID to find the D-Bus permissions an app needs. Add back only what the logs and tests show you need.
Try it yourself
The reachability demo shows how knowing what code can actually be reached cuts noise. Click through it and apply the same idea to permissions: what can your app really reach?
Click through it at your own pace, or open it full screen.
Quick check
Does filesystem=host include my home folder?
Yes. The documentation says host includes home, apart from ~/.var/app.
Can permissions use variables?
No. The documentation says permissions are static and variable expansion is not supported.
Safeguard's reachability analysis and dependency scanning help show which packages in an app matter most. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
