Dne 03. 07. 24 v 15:25 Neal Gompa napsal(a):
On Wed, Jul 3, 2024 at 9:17 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote:Dne 02. 07. 24 v 13:49 Neal Becker napsal(a): On Tue, Jul 2, 2024 at 5:59 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote:Dne 01. 07. 24 v 22:58 Aoife Moloney napsal(a):Wiki - https://fedoraproject.org/wiki/Changes/UnprivilegedSystemFlatpakManagement Discussion thread - https://discussion.fedoraproject.org/t/f42-change-proposal-unprivileged-management-of-system-flatpaks-system-wide/124336 This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == This proposal adds a new dedicated `flatpak` group, allowing users to manage system Flatpaks without needing to be in the `wheel` group. == Owner == * Name: [[User:boredsquirrel| Henning]] * Email: boredsquirrel@xxxxxxxxxxxxxxxxxx == Detailed Description == Currently, to install, uninstall and modify apps or repositories, users need to be in the `wheel` group. Removing a user from the wheel group would interfere with the currently default (systemwide) configuration of Flatpaks. All users can add a `user` repository, and manage their own user Flatpaks. But a dedicated group to manage system flatpaks, without relying on `wheel` allows more fine grained privileges.I am not Flatpak user, but I wonder why Flatpaks are system wide installed by default? And if it would not be better to make them user installed instead of this proposal. VítThis enables an "admin" permission that is not tied to full root access on the host system. It will be a change of the polkit rule `org.freedesktop.Flatpak.rules` like following: polkit.addRule(function(action, subject) { if ((action.id == "org.freedesktop.Flatpak.app-install" || action.id == "org.freedesktop.Flatpak.runtime-install"|| action.id == "org.freedesktop.Flatpak.app-uninstall" || action.id == "org.freedesktop.Flatpak.runtime-uninstall" || action.id == "org.freedesktop.Flatpak.modify-repo") && subject.active == true && subject.local == true && ( subject.isInGroup("wheel") || subject.isInGroup("flatpak"))) { return polkit.Result.YES; } return polkit.Result.NOT_HANDLED; }); polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.Flatpak.override-parental-controls") { return polkit.Result.AUTH_ADMIN; } return polkit.Result.NOT_HANDLED; }); == Feedback == none yet == Benefit to Fedora == This is a step towards the Confined Users goal. It enables a dedicated action, the management of Flatpaks, without needing all the other privileges that `wheel` users have. == Scope == * Proposal owners: changing a single rule, testing with nonwheel users in the `flatpak` group * Other developers: none * Release engineering: [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: Documentation needs to get an additional chapter on Flatpak management with the `flatpak` group. * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: Yes == Upgrade/compatibility impact == The polkit rule will be overwritten, there will be no changes in behavior. It just enables a new feature. == How To Test == On Atomic or traditional Fedora, place the above rule in `/etc/polkit-1/rules.d/org.freedesktop.Flatpak.rules`. This will be preferred over the default rule and you can test if it works. == User Experience == By default, Anaconda puts users into the `wheel` group. There will be no change. But it enables to manage Flatpaks without being in that privileged group. == Dependencies == None == Contingency Plan == * Contingency mechanism: this is a simple fix, not adding it will keep the previous wheel need * Contingency deadline: N/A * Blocks release? N/A == Documentation == Will be added afterwards. Nonwheel users can be added to the `flatpak` group: sudo groupadd flatpak sudo usermod -aG flatpak USERNAME == Release Notes == Permission to manage systemwide flatpaks is now granted to users in the 'flatpak' group.Currently wheel is required in order to install packages with dnf/rpm. Why should flatpak be different? Because Flatpak can do that it seems. But mainly, for single user computer, it does not really matter, the application can be installed in user profile and it won't need any elevated privileges. For multi user computer, why the apps installed by one user should influence other users? Of course there might be system administrator who might install those system wide. But I also see other benefits. E.g. for user computers, if home is on separate partition, there might be more space then on the system partition. In my experience, the Flatpak runtimes might consume quite some space.For anyone running with the F33+ default storage setup with Btrfs,
The system which I was dealing with is older and upgraded to more recent Fedora. But if I remember correctly, the Flatpack runtimes were part of the reason why it was for a while stuck with older Fedora version, because the runtimes consumed so much space that it prevented system update.
And I still think that having some quota for system and user home to prevent these kind of issues is still good idea, no matter if Btrfs or other FS is used.
there are no practical space contention issues between storing per-user vs system-wide. Provided that reflinks are used by the flatpak software, there can be even more significant space savings because identical blobs on the system or per-user will be deduplicated in storage.
The deduplication would actually talk in favor of user installation, because otherwise one of the reasons for system installed Flatpack could be the space savings.
Vít
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
