Is there a reference page that describes what each default group’s semantic meaning is in Fedora? I noticed that I have a group called users, but my users don’t seem to be members of this group, so I wondered if this group is somehow special, and more generally what each group is used for.
There’re only 2 groups relevant to most users:
-
wheel
which is for admin permissions -
your User Private Group, which is the group with the same name as your user.
Note that your UPG in
/etc/group
will not explicitly include your user (and there’s no need to change this). Your user in/etc/passwd
will have its default group set as the UPG’s group ID.
I don’t think the users
group has any practical use now, at least I haven’t thought about it in 10 years.
Most modern desktop distros are designed around individual users who are also their own local administrator, so the grouping should be fairly straightforward.
Some programs packaged in Fedora will set up their own user/group, commonly for servers/daemons.
Some users and groups could be just for POSIX and legacy compatibility with no practical usage.
For additional information, you may want to inspect the contents of sysusers.d.
Well, to me, there are several groups that still have function. For example:
realtime: allows pipewire to use rtkit and gain realtime.
mock: let’s me use mock’s chroots.
kvm/qemu/libvirt: allow me to use virt-manager without issue.
pipewire: allows several limits settings useful for audio.
So, as you see, they are still useful and used around Fedora. At least it seems so.
I don’t think those are applicable to most users, but definitely, there are groups for specific use cases.
mock group setup is documented in the manual; I assume mock will not work correctly if the user tried to proceed without it, so the user will find out naturally.
PipeWire realtime is documented on their wiki, and I don’t want to make general desktop users think they need it (once that kind of myth spreads it’s hard to stop, like gamers trying to use realtime kernels because they think it will give them more performance).
Was just looking at this, myself, after a random thought. It is disappointing that it’s so difficult to find this documentation. I don’t see how the system could keep this updated, correctly, over updates, unless it’s tracking all users above uid 1000–I think it’s 10000 now, right?-- and manage group memberships. But, I’m not aware of that being implemented. It really should be written down in release notes or other docs.
The number of groups has grown dramatically. Some of them mediate hardware access, right? I guess we are supposed to research all 130 of them?
I think that’s some of what your looking for.
I did find that, earlier. It is a good reference, but it doesn’t explain what the groups are for or what access they grant.