Repository navigation
[Bug report]: -y flag prevents polkit auth dialog from appearing #6085
Description
Activity
I don't quite follow the problem. There's no need to run
flatpakas root or any other user for normal operations (install/update). From an unprivileged user account, flatpak will authenticate with polkit, and the polkit agent will ask for the administrator account's password. (GNOME's agent doesn't let you select which admin account to use but that's not a Flatpak issue.)flatpak installauthenticates in the middle of the transaction (before deploy), rather than at the beginning, which isn't ideal UX, but it does fundamentally work (at least for me). What aspect of this isn't working for you?Please update the app exports for all logged in users when installing apps.
This mostly works automatically by session components watching the export directories for changes. You can have issues with the first app installed into an empty installation because those components can't watch directories that don't exist yet. For D-Bus session services, this was fixed in #5720, but that only works for the invoking user (another reason to run
flatpakas the active user). Reloading the session bus configuration of all logged in users would be a lot more work. As an alternative, multi-user installations should ensure that at least one app is pre-installed, or that the export directories are pre-created.Don't show warnings when the root user installs flatpaks. Or maybe we find a better way to do this, like with su but without suid
This can be avoided by not running
flatpak installas root (see above).remove all appdata from all logged in users when executing flatpak remove --delete-data from a different user
I think I can safely say that's not going to happen. The contents of app data directories belong to that user, the same as with other data in the home directory.
--delete-datamainly just removes a directory; there's no reason why a third-party tool couldn't handle managing that for multiple users if there's a need. (It also does the equivalent offlatpak permission-reset, which would be a little harder to manage from outside, but it wouldn't be any easier for Flatpak to do it.)Btw. I see how user-flatpaks are an issue here. Mounting /home non-executable could solve this.
Outside of a locked down kiosk-type scenario, preventing users from executing downloaded code is very difficult. See https://unix.stackexchange.com/a/767326
@chrisawi yes you are right, this should be the normal behavior? But it isnt.
flatpak remove --delete-data -y doorknocker KENNUNG Zweig Op 1. [✗] xyz.tytanium.DoorKnocker stable r 2. [ ] xyz.tytanium.DoorKnocker.Locale stable r Error: Flatpak system operation Uninstall not allowed for user Error: Failed to uninstall xyz.tytanium.DoorKnocker: Flatpak system operation Uninstall not allowed for userflatpak remove --delete-data -y doorknockerIt's not working because of
-y(--assumeyes). I can reproduce that behavior in my test VM. I don't know why it happens though, will have to investigate.I don't know why it happens though, will have to investigate.
It's because
-ysetsflatpak_transaction_set_no_interaction(), which seems a little odd when there's a separate--noninteractiveoption for that. I would only expect-yto answer yes to yes/no questions, not completely disable user interaction.Reacted by boredsquirrelokay but just authenticating with the user, when not using the -y flag, works normally.
- changed the title
[-][Feature request]: Support separate admin users[/-][+][Bug report]: -y flag prevents polkit auth dialog from appearing[/+]on Jan 29, 2025
Checklist
Suggestion
Why this is needed
In all enterprise, school etc systems, general users are not admins. This is important for the change to replace Windows with Linux, so we need to address this need.
The default Flatpak polkit rule sets the starts for this:
wheel/sudogroup access is enough to be able to install and remove packages and remotesThe problems