Making Fedora usable for nonwheel users

I think this goal is quite important.

There are many deployments, especially for autoupdating (atomic) systems, where an admin may want to set things up once, and then barely have to touch it again.


  • school “Chromebooks”
  • child/parent laptops ;D
  • company workstations

Having this working is not a huge issue but requires some small adaptions. dnfand rpm-ostree need to work without sudo rights. There need to be dedicated groups for privileged actions, to avoid needing to be in the wheel group.

There are many security benefits when not using “the default”, a user whose password can also be used to access, and break, the entire system.

Using dedicated groups with associated polkit actions, for flatpak,adb, libvirt, partitioning, … will be a part of this.

Who is interested in joining this goal, test things out, create implementations to make Fedora usable day to day, without needing to be in the wheel group?

1 Like

Hmmm. Can you elaborate more on the use case here?

If the goal is to make accidental breakage more difficult, this might help. But it also adds a lot of complication — and, I’m not sure it really offers much of a security benefit (at least not with some other major changes). If you have the ability to install arbitrary packages via DNF, you can run arbitrary code as root.

Added engineering

Use case: having unprivileged users use a built system.

Maintenance is automated in the background. The users cannot install but upgrade packages.

And the complications come from using dedicated groups for certain privileged actions, instead of “the wheel workaround”.

Like these said groups, if wanted.


This could have multiple ways.

Either allow users to modify their apps, by using --user repos. This does not need any privileges.

Or keep the standard with systemwide flatpaks and having users in the flatpak group. I think this is the default.

Or install some system flatpak apps and dont put users in the flatpak group, meaning they cannot install random stuff. In this scenario it needs to be sure that automatic flatpak updates still work, but nothing else.

I’m not trying to be snarky… I think this really needs a more solid definition of “users” and “use”. Is the user a random person at a kiosk? A family member? A student using a school-provided laptop? At work, a software developer? A designer? An office worker? What applications do they use and need?

Maybe use the “user story” format? (“As an embedded hardware developer, I need to access serial ports, so that I can deploy code to and debug microcontrollers connecting via USB.”, etc.)

This should currently be the case with GNOME Software.

Libvirt is already configurable with polkit, although to be completely honest I don’t remember how to do it nicely with the “new” javascript-based policy definitions.

I edited the post. The focus is on unprivileged users doing unprivileged stuff, accessing their user account, managing files, using apps etc.

With the scope of fixing issues that arise here. It may be that this is already the case, but it wasnt.

Additional to this base use, more privileges should all be possible to add without needing the wheel crutch.

I use that libvirt polkit rule but for some reason it doesnt work anymore, will need to debug.

This means

  • testing (especially on rpm-ostree where it currently does not work but I have a change proposal for that)
  • documentation of safe privilege extension