Skip to main content

Managing local group accounts in Linux

Managing user resource access through groups is a tried-and-true strategy that still works.
Image
Managing local groups in Linux
Image by PatternPictures from Pixabay

As human beings, when we discover a new object, our brain does a couple of things. One, we see the utility of the object. Two, we assign the object a group so that we know how to classify it moving forward. For example, if a child discovers a hammer, they generally are aware that it could be used to hit things. They then assign the hammer to a group. In some cases, the child labels the hammer as a tool and will only use it to accomplish a task. In others, the child will label the hammer a toy. However, the utility of the hammer is still apparent, so be sure to watch out for the latter child. This is why grouping matters.

Groups in Linux are important because users are present on the system for a defined utility. Grouping users by utility (or access) is a fantastic way to ensure that only admins have admin privileges and that general users can only access files that they are meant to. Users are broken down into three distinct classifications to make the grouping process a little easier:

  • Superusers - responsible for the administration of the system. The root account is the chief superuser and has UID 0.
  • System users - user accounts used by the system itself to run processes or daemons. Each of these users has its own files and resources. Ideally, users do not log in as a system user. The range of UIDs is 1-999.
  • Regular users - accounts that most of us use to accomplish our daily work. They are limited in their access to files and systems and must obtain sudoer permissions to perform administrative tasks. The UIDs start at 1000+.

If you would like further information on basic user and group concepts, check out Ken Hess' article User account management with UIDs and GIDs. For the rest of this piece, I focus on group creation, membership, and identification codes, as well as how to assign superuser privileges to a group.

Primary group

All users are assigned to a primary group by default. For local accounts, the primary GID is the same as the one listed in the /etc/passwd file. This means that the user name and the group name are the same. It also means that the user is the sole member of that group. For example:

[root@server ~]# useradd user01
[root@server ~]# su - user01
[user01@server ~]$ id
uid=1002(user01) gid=1002(user01) groups=1002(user01) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

This design's side effect is that it makes managing file permissions much simpler for the users and administrators. If you wish to collect users into a primary group for a common purpose, you need to create a group and then assign the desired users to it.

[ You might also like: Linux sysadmin basics: User account management ]

Group creation

For our demonstration, I am going to create the group demogroup. You can see from the output that the group has been created and assigned GID 1007:

[root@server ~]# groupadd demogroup
[root@server ~]# tail /etc/group
cockpit-wsinstance:x:975:
flatpak:x:974:
rngd:x:973:
admin:x:1001:
user01:x:1002:
user02:x:1003:
user03:x:1004:
user04:x:1005:
user05:x:1006:
demogroup:x:1007:

Now let's change the GID to 10007:

[tcarrigan@server ~]$ sudo groupmod -g 10007 demogroup 
Output Omitted
[tcarrigan@server ~]$ sudo tail /etc/group
Output Omitted
demogroup:x:10007:

Use the groupmod -g GID groupname syntax to change any group's GID if needed. If you need to change a group's name, use groupmod -n NEWNAME oldname. Here is an example:

[tcarrigan@server ~]$ sudo groupmod -n usergroup demogroup 
[tcarrigan@server ~]$ sudo tail /etc/group
Output Omitted
usergroup:x:10007:

Note that we renamed demogroup to usergroup. The group is still the same, as indicated by the GID 10007.

Adding users to a group

A group without members is like a forest without trees. So how do we add a few members? Easy to do.

[tcarrigan@server ~]$ sudo usermod -g usergroup user01
[tcarrigan@server ~]$ sudo usermod -g usergroup user02
[tcarrigan@server ~]$ sudo usermod -g usergroup user03
[tcarrigan@server ~]$ sudo usermod -g usergroup user04
[tcarrigan@server ~]$ sudo usermod -g usergroup user05

You can see the change in GID and group name from when we created user01 at the start of this exercise.

[user01@server ~]$ id
uid=1002(user01) gid=10007(usergroup) groups=10007(usergroup) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Supplementary group

Now, a user can also belong to a supplementary group. A supplementary group is just that—supplementary. A very popular use for supplementary groups is to assign administrative privileges via sudo.

For example, if user01 needs to change permissions for other users in usergroup, without assigning admin permissions to the entire group, we assign user01 to a supplementary group with admin permissions. On many systems, the wheel group is used for just such occasions.

To add wheel as a supplementary group to user01:

[tcarrigan@server ~]$ sudo usermod -aG wheel user01
[tcarrigan@server ~]$ su - user01
Output Omitted
[user01@server ~]$ id
uid=1002(user01) gid=10007(usergroup) groups=10007(usergroup),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

NOTE: The -a option forces usermod into append mode. If the -a option is not used, the user is removed from any other supplementary groups not listed in the -G option's list.

You can now see that user01 has a primary group (usergroup) and a supplementary group (wheel).

Sudo group config

What if we need to give admin privilege to the entirety of usergroup? To accomplish this, we need to create the /etc/sudoers.d/usergroup file:

[root@server ~]# echo "%usergroup ALL=(ALL) ALL" >> /etc/sudoers.d/usergroup
[root@server ~]# su - user02
[user02@server ~]$ sudo cat  /etc/sudoers.d/usergroup
[sudo] password for user02:  
%usergroup ALL=(ALL) ALL

You can see above that user02, a member of usergroup, now has admin privileges. For more information on admin privileges and the sudoers file, check out my previous article Linux command line basics: sudo.

[ Want to test your sysadmin skills? Take a skills assessment today. ] 

Why should you care?

If you ask yourself the above question, think practically about the following concepts: Using groups in Linux is a fundamental part of the operating system and is even required to run various applications. Assigning users to easily-controlled groups is a great way to quickly increase security on your systems and manage multiple user accounts. As shown above, you can allow certain users to access admin privileges to get specific work finished without giving them root access to the system. If we can keep our users organized and productive, while ensuring that they only have access to what they need, we make our lives easier, and our user-to-admin relationships will be a bit less stressful. Your organization will benefit from these improvements from the ground up, whether they know it or not.

Author’s photo

Tyler Carrigan

Tyler is the Sr. Community Manager at Enable Sysadmin, a submarine veteran, and an all-round tech enthusiast! He was first introduced to Red Hat in 2012 by way of a Red Hat Enterprise Linux-based combat system inside the USS Georgia Missile Control Center. More about me

Try Red Hat Enterprise Linux

Download it at no charge from the Red Hat Developer program.