Imagine you are the admin of a server with 500 employees. Do you really want to manually edit permissions for every single file for every single user? No, you don’t. You’d go mad ( that’s why we have group management 😊 ). Or, if you are looking at this from a hacker’s perspective (which, let’s be honest, is why you are here), understanding groups is critical for Privilege Escalation. If you compromise a user who is part of the docker or sudo group, you practically own the box.
So, in this article, we aren’t just memorising commands; we are learning how to organise, control, and secure the hierarchy of the Linux filesystem.
Let’s get cracking.
- What Exactly is a Group?
- Phase 1: Reconnaissance (Showing Groups)
- Phase 2: Building the Team (Creating Groups)
- Phase 3: Dismantling the Team (Deleting Groups)
- Phase 4: The Secret Sauce (Group Passwords)
- Why Does Group Management Matter for Cyber Security?
- What’s Coming Next?
- Frequently Asked Questions (FAQs)
What Exactly is a Group?
Before we start typing commands, let’s conceptualise this.
In the physical world, think of a corporate office. Everyone has an ID card (the User). But that ID card doesn’t open every door. The “HR Team” can open the filing cabinets. The “IT Team” can open the server room. The “Interns”… well, they can open the front door and the coffee machine.
In Linux, a Group is just a logical collection of users who share a common requirement for file access.
By default, when you create a user (like we did with useradd), Linux usually creates a group with the exact same name as the user and puts them in it. This is called a Primary Group. But the real magic happens with Secondary Groups—the extra clubs you join that give you special powers.
Phase 1: Reconnaissance (Showing Groups)
As a hacker, the first thing you do when you land a shell on a compromised machine is look around. You need to know who is who and, more importantly, who belongs to what.
There are three main ways to check out the group situation on a Linux box.
1. The Raw Data: cat /etc/group
This is the source of truth. The /etc/group file is a plain text file that defines the groups on the system.
Open up your terminal and type:
cat /etc/group
You are going to see a flood of text. Don’t panic. It might look like root:x:0: or sudo:x:27:kali. Let’s break down the syntax because understanding the structure is half the battle.
The format is: group_name:password:GID:user_list
- group_name: Obviously, the name of the group (e.g.,
sudo,adm,www-data). - password: Usually, you’ll see an
xhere. This means the password is encrypted and stored in/etc/gshadow(we will talk about group passwords later—yes, they exist!). - GID (Group ID): The numeric ID associated with the group.
0is always root. - user_list: A comma-separated list of the members of this group.
Pro Tip: If you are hunting for targets, you might want to grep for interesting groups immediately:
grep "sudo" /etc/group
If you see a user in there that you have the password for… balle balle, you’ve just found a path to root.
2. The Systematic Approach: getent group
While cat is great, it only reads the local file. In enterprise environments (where you might be doing a penetration test), users and groups might be stored on a network server (like LDAP or Active Directory). cat /etc/group won’t show you those.
That is where getent (get entries) comes in. It fetches entries from the databases configured in your system.
getent group
It looks similar to cat, but it’s more robust. If you want to check a specific group, say, the adm group:
getent group adm
3. The Quick Check: groups
Sometimes you don’t care about the whole system; you just want to know what groups a specific user belongs to.
If you just type groups on its own, it shows the groups for the current user (you).
groups
# Output: kali adm cdrom sudo dip plugdev kvm
If you want to snoop on someone else, just append their username:
groups lallu
This is your “who am I” check. If you compromise a user, run groups immediately to see if you have permission to read logs (adm group) or mount drives (plugdev).
Phase 2: Building the Team (Creating Groups)
Right, so we know how to look at groups. Now let’s play sysadmin and create some.
We have two main commands for this: groupadd and addgroup.
Now, listen carefully—this is a bit confusing. groupadd is the standard binary found on almost all Linux systems (RedHat, CentOS, etc.). addgroup is usually a friendlier Perl script found on Debian/Ubuntu/Kali systems that actually runs groupadd in the background but with nicer interactive prompts.
Since we are hackers using Kali (which is Debian-based), we will use addgroup, but keep groupadd in the back of your mind.
a. Creating a new group
Let’s create a group for our elite hacking team. We’ll call it fsociety.
sudo addgroup fsociety
Note: You need sudo because you are editing system files.
If you run this, Linux will automatically pick the next available GID (usually 1000+) and create the entry in /etc/group.
b. Adding a user to a group
Now, a group with no members is just an empty room. Let’s put a user in there.
In the previous article, we used usermod -aG. That works perfectly. But since we are talking about addgroup, there is a corresponding syntax in Debian systems that feels a bit more natural.
To add the user kali to the group fsociety:
sudo adduser kali fsociety
See how easy that reads? “Add user kali to fsociety”.
Warning: Be very careful if you fall back to using usermod. Always remember the -a (append) flag. If you just do usermod -G fsociety kali, you will overwrite all their existing groups and kick them out of sudo. I’ve done that once. Locked myself out of root. Had to reboot into recovery mode. Bahut headache tha (It was a huge headache). Don’t be like me.
Phase 3: Dismantling the Team (Deleting Groups)
Sometimes, projects end. The fsociety team disbands. We need to clean up the system.
The command here is quite logical:
sudo delgroup fsociety
And just like that, the group is gone from /etc/group.
Here is a critical question for you to ponder: When you delete a group, what happens to the files that were owned by that group?
They don’t get deleted. They don’t change ownership. They remain on the disk, but now they are owned by a GID that doesn’t map to a name anymore. If you ls -l those files, you’ll just see a number (e.g., 1002) instead of a group name.
From a security perspective, this is a potential vulnerability. If I create a new group later and it happens to grab that recycled GID (1002), the new group suddenly has access to the old group’s secret files. Always audit your filesystem for “orphaned” group IDs!
Phase 4: The Secret Sauce (Group Passwords)
Okay, now we are getting into the territory that many modern sysadmins forget, but hackers love. Group Passwords.
Wait, groups have passwords? Since when?
Since always. Most people rely on sudo these days, but historically, Linux allows you to password-protect a group. If you know the password, you can temporarily change your primary group to that group, effectively “becoming” a member of it for a session.
a. The Structure: /etc/gshadow
Just like /etc/passwd has /etc/shadow to hide user hashes, /etc/group has /etc/gshadow.
Let’s take a peek (you’ll need sudo):
sudo cat /etc/gshadow
The format looks like this: group_name:encrypted_password:administrators:members
- Group Name: The name of the group.
- Password: Usually
!or*(meaning no password/locked). If there is a hash here, the group has a password. - Administrators: Users who can manage this group (add/remove members) without needing full root privileges.
- Members: Regular members.
b. Managing Group Passwords: gpasswd
The tool to manipulate this is gpasswd.
Let’s say we want to assign a password to our fsociety group. Maybe we want users who aren’t officially members to be able to join it if they know the secret code.
sudo gpasswd fsociety
It will prompt you to enter a new password.
Now, let’s say I want to make the user lallu an administrator of this group, meaning he can add other people to it.
sudo gpasswd -A lallu fsociety
This is a great persistence mechanism for hackers. If you compromise a box, create a group, make yourself the admin of it, and then you can add/remove users or set passwords to bypass standard controls later.
c. Switching Context: newgrp
So, we have a group password. How do we use it?
Imagine I am logged in as user bob. Bob is NOT in the fsociety group. If he tries to read a file owned by fsociety, he gets “Permission Denied”.
But, Bob knows the group password. He can run:
newgrp fsociety
Linux will ask for the password. If Bob types it correctly… boom! He is now logged in with fsociety as his Primary Group.
Any file Bob creates now will be owned by fsociety by default. This is incredibly useful for shared directories where multiple users need to edit the same files without messing up permissions.
To get back to his normal self, he just types exit.
Why Does Group Management Matter for Cyber Security?
You might be thinking, “This is just administrative work.”
Not quite. In the world of hacking, Privilege Escalation is the game.
- Misconfigured Groups: If you find a sensitive file (like
/etc/shadow) that is readable by a group, and you can get into that group, you win. - Docker Group: If you can add yourself to the
dockergroup, you can mount the host OS filesystem into a container and read anything as root. It is practically a root equivalent. - LXD/LXC: Same logic. Group membership often equals root access in modern containerised environments.
- Sticky Bits & SGID: We will cover permissions in a future article, but understanding how groups interact with the
setgidbit is crucial for backdoor creation.
What’s Coming Next?
We have our users. We have our groups. We have organised our chaos. But a computer without software is just a very expensive heater.
In the next article and video, we are going to talk about “How Packages Work in Linux”. We aren’t just doing apt install; we are going to look at repositories, how the package manager actually finds software, and perhaps how to sneak malicious packages in.
So, finish that coffee (or make a new one, I won’t judge), practice these commands, and get comfortable with the group structure.
Check the FAQs below if you have specific doubts, otherwise, I’ll catch you in the next one!
Frequently Asked Questions (FAQs)
Q: What is the difference between useradd and adduser? A: Great question. useradd is the low-level binary command that works on almost all Linux distros. It’s strict and doesn’t set up home directories unless you tell it to. adduser is a high-level Perl script (common on Debian/Ubuntu) that is interactive and friendlier—it sets up home folders and shell defaults automatically. Think of useradd as the manual transmission and adduser as the automatic.
Q: Can a user belong to multiple groups? A: Absolutely. A user has one Primary Group (usually their username) and can have many Secondary (or Supplementary) Groups. You can see all of them by typing groups.
Q: Is it safe to delete the group that has the same name as a user? A: Generally, no. That is their primary group. If you delete it while the user still exists, the user’s files will have a “floating” GID, and things might break. Usually, when you userdel a user, Linux will delete their primary group automatically.
Q: What is the wheel group? A: In many distributions (like CentOS/RedHat/Arch), the wheel group is the administrative group, similar to sudo on Debian/Ubuntu. Members of wheel can usually run commands as root.
Q: Can I change the Group ID (GID) of an existing group? A: Yes, using the groupmod -g command. But be careful—files owned by the old GID won’t automatically update to the new GID. You’d have to manually find and fix them using chown. It’s usually more trouble than it’s worth!
