tl;dr; Flatpak currently considers remotes as trusted, so after you have added one with a password at system level, you don't need a password to install apps for that remote.
I don't about how polkit rules work, but this is just a comment describing what happens from a user perspective with flatpak. If you want to tighten it, I suggest discussing with upstream to ensure docs or any other assumptions etc are correct (please also ensure any changes make it into Debian, generally we have been able to avoid diffs with Debian so far - we do have a diff right now as Debian is in freeze). - Flatpak has two locations that you can add remotes and install apps to, user level and system level. System level ones are available to all users, user level ones are available to just that user - Adding a flatpak remote or installing an app at *user* level does not require any password So far I think this all makes sense, the interesting part up for debate is the next part. - When a remote is added to flatpak at *system* level, it asks for a password to verify the remote - When an app is installed at *system* level for this trusted remote, it installs without needing a password (as stated in previous comments, assuming the user is in the wheel group) To try this out you can do the following commands, the remote-add and remote-delete will need a password, the install and uninstall won't. $ flatpak remote-add --if-not-exists kdeapps --from https://distribute.kde.org/kdeapps.flatpakrepo $ flatpak install kdeapps org.kde.kate $ flatpak uninstall org.kde.kate $ flatpak remote-delete kdeapps -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1812456 Title: [MIR] libflatpak0 Status in flatpak package in Ubuntu: New Bug description: Many applications have Flatpak integration using libflatpak. The Ubuntu desktop team would like libflatpak0 in main so we can easily build such applications. It takes a lot of work to make these dependencies optional and sometimes that is not possible. We don't need the Flatpak functionality to work by default and do not expect any other Flatpak packages to be installed by default. Default packages that have flatpak integration: - gnome-control-center (application panel). - malcontent (parental controls) Availability ============ In Universe, builds for all architectures and in sync with Debian. Rationale ========= Multiple default packages have libflatpak as a dependency, including malcontent (LP: #1892456). Security ======== This will need a Security review. https://security-tracker.debian.org/tracker/source-package/flatpak There have been two CVEs, both have been fixed in all supported Ubuntu releases. More recently, there is LP: #1815528 Quality Assurance ================= Bug subscriber: should be Ubuntu Desktop Bugs https://bugs.launchpad.net/ubuntu/+source/flatpak https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=flatpak https://github.com/flatpak/flatpak/issues tests are run as build tests (with dh_auto_test) and installed autopkgtests on Debian and Ubuntu. https://ci.debian.net/packages/f/flatpak http://autopkgtest.ubuntu.com/packages/f/flatpak UI Standards ============ N/A Dependencies ============ All in main except for libostree-1-1 (LP: #1892454) Standards Compliance ==================== Package uses standards version 4.5.0. Maintenance =========== - Actively developed upstream https://github.com/flatpak/flatpak - Maintained in Debian by the pkg-utopia team but more specifically, it is maintained by Simon McVittie (smcv) who maintains Flatpak, ostree, xdg-dbus-proxy, xdg-desktop-portal and xdg-desktop-portal-gtk. short dh7 style rules, dh compat 10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/1812456/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
