F42 Change Proposal: Unprivileged management of system Flatpaks (system-wide)

Project Discussion Change Proposals
,
1

Unprivileged management of system Flatpaks

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.

Wiki
Announced

:link: Summary

This proposal adds a new dedicated flatpak group, allowing users to manage system Flatpaks without needing to be in the wheel group.

:link: Owner

:link: Current status

  • Targeted release: Fedora Linux 42
  • Last updated: 2024-07-01
  • [Announced]
  • [ Discussion thread]
  • FESCo issue:
  • Tracker bug:
  • Release notes tracker:

:link: 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.

This 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;
});

:link: Feedback

See below

:link: 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.

:link: Scope

  • Proposal owners: changing a single rule, testing with nonwheel users in the flatpak group

  • Other developers: none

  • Release engineering: #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

:link: Upgrade/compatibility impact

The polkit rule will be overwritten, there will be no changes in behavior. It just enables a new feature.

:link: 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.

:link: 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.

:link: Dependencies

None

:link: Contingency Plan

  • Contingency mechanism: this is a simple fix, not adding it will keep the previous wheel need
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No

:link: Documentation

Will be added afterwards.

Nonwheel users can be added to the flatpak group:

sudo groupadd flatpak sudo usermod -aG flatpak USERNAME

:link: Release Notes

Permission to manage systemwide flatpaks is now granted to users in the ‘flatpak’ group.

Last edited by @boredsquirrel 2024-07-02T21:20:40Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply giving that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

And what if my work to allow Flatpak’s to provide system extensions lands in Flatpak/etc? That would essentially allow you to install a Flatpak which alters the system /usr and /etc at large.

Should that require wheel?

4

This is also part of su-confined-users

5

Flatpaks are normally isolated from your OS core, that is the concept.

This is the first time I heard of this, but if you have a special use case for this, you can always disable the rule by copying it from /usr/share/polkit-1/rules.d/ to /etc/polkit-1/rules.d/ and replacing the polkit YES with AUTH_ADMIN

6

@amoloney it is correct that I am too late for F41 right?

7

Currently that is sort of accurate, but there is work ongoing to expand it to allow for applications which have privileged components to integrate with the host operating system through systemd sysext.

https://blogs.gnome.org/chergert/2024/05/07/system-extensions-from-flatpak/

1 Like
8

Interesting. Still, this rule

  • can be neutralized
  • if users are not in the flatpak group they dont get any new capabilities

Please read more carefully

9

Will the users from the flatpak group have full flatpak-related rights, e.g. add remote repositories, install from sideloaded repos etc?

10

As this is a SystemWideChange, this is too late for F41: Fedora Linux 41 Schedule: Key

All unprivileged users can already install their own “user” Flatpaks without privileges right now.

There is currently almost no difference for a Flatpak if it’s installed system wide or user wide.

Christian Hergert’s work will make system installed Flatpak different but then we can not grant full control to unprivileged users as that would be equivalent to root access.

So what would be the benefit of this change?

As I wrote in F42 Change Proposal: Unprivileged Disk Management (system-wide) - #7 by siosm, I don’t think adding more groups brings us any closer to the Confined Users goal. Instead, this will create a new “privileged” status for some users which are part of all those groups.

In F41 Change Proposal: Unprivileged updates for Fedora Atomic Desktops (Self-Contained) - #17 by siosm & Allow Flatpak metadata-refresh without password for non-admins?, we were looking at enabling metadata refresh & updates operations only, not full management.

2 Likes
11

Yes, they have all privileges that wheel users currently have.

It simply removes the need for wheel, thats all.

1 Like
12

Right, updating flatpaks should be included in the “unprivileged updates” change.

User Flatpaks cause annoying duplication, increasing network consumption and storage space. On multi-user systems, being able to just manage the Flatpak apps would grant some privileges but not all.

Yes this changes things a lot. If this can not be disabled, being allowed to use system flatpaks could be a loophole.

Still, currently to manage flatpaks users need to be in wheel, which is always bad.

But yes, system extensions are problematic


I dont understand that. It adds a group for users to do one thing. These things currently tie users to the wheel group, so on Fedora a good UX can only ge granted if the user is in wheel.

Otherwise there will be some things not working, which may be very annoying.

These rules also dont change any setup, they just allow easily granting access, instead of needing to modify a polkit rule (which is pretty tedious)

13

I can’t edit the post, this seems to be a Discourse bug. Here is the correctly formatted rule:

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;
});
14

Passive aggressive comments like this are completely unnecessary.

I’m only asking what you think of the situation if we were to have that feature in Flatpak. In that if you are in the flatpak group you are essentially wheel anyway, is that something that causes unexpected behavior?

3 Likes
15

Who this change is targeted at? Multi-user systems where disk/network usage is a high concern and where users need to manage shared applications but not have wheel? That seems like a pretty specialized use case where it make more sense for the user to make this change instead of a default change.

If the goal is confinement, it would make more sense to use user flatpaks instead of system flatpaks for most common use cases.

Systems that are multi-user and make material use of flatpaks and want users to be able manage their own applications and don’t want to allow user flatpaks seems like a pretty uncommon use case.

4 Likes
16

Sorry I realised that sounded passive aggressive. But it was really just meant like that.

Poorly I cannot edit the rule, but you can have a look at the comment above yours.

I think the feature is probably pretty great. If installing system extensions is a somehow differentiated action, it can get a different polkit action and rule.

If all users can install, remove, update and metadata-refresh system flatpaks anyways, this flatpak group could be used less.

I have to look into your blog post. Are these extensions on Flathub? How would they grant root access?

I imagine a malicious extension could be installed, but that would either require

  • installing a local package
  • adding another repo

Which could be differentiated like it is currently done. Adding a remote requires a password.

This gets complicated, and I am not sure what the correct approach is anymore


Maybe


  1. All users can update system flatpaks and of course do whatever they want with their user flatpaks
  2. flatpakuser users can install and uninstall system flatpaks
  3. flatpakadmin users can add repos or install local packages etc
  4. wheel users can add flatpak system extensions.

3 and 4 could be merged

1 Like
17

No, even if you are the only user, it makes sense to restrict your own privileges. Running a process under a wheel user is like running it as root, to quote @siosm roughly.

This would allow users that just want that, to remove themselves from wheel and add themselves to that group.

For sustainability, the “developing world” and low-storage devices, yes I think we should never forget these aspects.

If I have a Chromebook with 64GB of storage, it should allow a more isolated user with specific permissions, and an admin user with all of them.

I should be able to install a single runtime and all apps on top of that. Or at least “just” 3 (like the state Flathub is currently in).

I disagree here. They work pretty much the same (apart from flatpak system extensions, and GPU screen recorder).

But now imagine you have a system with core apps installed as system apps. Because they are preinstalled, like Fedora Atomic variants do it. These apps are using the Fedora runtime.

In Plasma Discover, if users click on “add flathub”, the system flathub repository is installed.

Now if you add the flathub or fedora remote for your user, you duplicate that. Now you have twice the disk space. If you get apps from Flathub, there are 3 runtimes (FDO, GNOME, KDE). These have about 3 not-EOL versions each, all used by various apps and thus often installed in parallel.

You could also have nonfree flatpak system extensions, for example for thumbnails or ffmpeg or whatever. These have to come from flathub, for legal reasons.

So you have at least

  • preinstalled system Fedora apps and runtime
  • system flathub runtimes and system extensions
  • user flathub runtimes and apps, for each user

This is not scaleable. On a system where everything should be done with Flatpaks, a system flatpak (flathub) repository just makes the most sense.

Also, user flatpaks dont get updates if the user does not use the system. They may have security vulnerabilities, and a central auto-update mechanism cannot prevent this.

So:

No, a single user too, with restricted permissions

Yes, all Atomic Fedora Variants, which may replace the traditional ones some time.

Yes that is the standard way. But you manage a single set of applications.

Yes I think user Flatpaks are flawed, as they allow to install random executable code without any privileges. But nobody says that user Flatpaks are not allowed, they are not touched by this Proposal and not in scope.

(Sorry for the long text)

18

Added f42, fesco

19

FYI, these changes are already on Phoronix :sweat_smile:

I will add your feedback to the proposal, and also some of my replies.

For example that for UX, ease of use, avoiding outdated packages and duplication, I dont see user Flatpaks as a real alternative to this Proposal.

20

This change has been rejected by FESCo and will not be included in Fedora Linux 42.

To find out more about how our changes policy works, please visit our docs site.