Summary: | Support editing XDG portals permissions of Flatpak programs | ||
---|---|---|---|
Product: | [Applications] systemsettings | Reporter: | SolidTemperature0 <i6icgp6> |
Component: | kcm_flatpak | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | CONFIRMED --- | ||
Severity: | wishlist | CC: | f.alexander.wilms, joshiesuhaas0, nate, postix, smcv |
Priority: | NOR | ||
Version: | 5.27.4 | ||
Target Milestone: | --- | ||
Platform: | Manjaro | ||
OS: | Linux | ||
See Also: | https://bugs.kde.org/show_bug.cgi?id=466325 | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
SolidTemperature0
2023-04-22 12:07:49 UTC
That's a reasonable request. I don't have any experience with portals API yet, but was about to look into it. Too bad those portals don't use the same overrides config file, so we'd have to get creative about loading and storing those permissions. [I am a Flatpak contributor, but not a regular Plasma user.] > Too bad those portals don't use the same overrides config file That's partly because the overrides for sandbox parameters (the equivalent of `flatpak override` in the CLI) are "owned" by Flatpak and are unique to Flatpak, whereas the permission store (the equivalent of `flatpak permissions` etc. in the CLI) is "owned" by xdg-desktop-portal and shared between Flatpak/Snap/anything else. This is extra-confusing because people use the word "permission" informally to describe both, but the Flatpak manual pages seem to be making a point of not using the word "permission" for the sandbox parameters. The sandbox parameter overrides are described as "overrides" because the typical use for them is to override the features for which the app author has said "this app won't work properly unless allowed to...", so they're advanced/risky/can very easily break apps. In the opposite direction, it's also very easy for configuring sandbox parameter overrides to give the app much wider access than you intended it to. It doesn't seem great that flatpak-kcm displays the sandbox parameters and encourages users to override them, but without exposing the safer and more normal-to-edit permission store settings - that seems like the wrong way round. I'd also prefer it if permission-store configuration had more emphasis (e.g. at the top), with the overrides labelled as "advanced" or similar. https://github.com/flatpak/flatpak/issues/5427 is an example of a situation where access to the permission store would have been useful. The particular permission store item that was relevant to that issue (the "run in background" permission) is available in GNOME's Settings (the equivalent of systemsettings), which intentionally *doesn't* expose the equivalent of `flatpak override`, leaving that to more advanced tools. |