User Account and Group Management

A Linux system is a multi-user environment, meaning many people can log into the same machine at the same time, each seeing their own files and running their own processes. To manage all these people securely, Linux uses user accounts and groups. Every person (or service process) that interacts with the system must have a user account. That account is identified by a username (the human-readable name) and a user ID (UID), which is a number the system uses internally. Linux does not care about the username — it cares about the UID.

When you install a fresh Linux system, it automatically creates a special user called root. The root user has UID 0 and is all-powerful: it can read, write, or delete any file, install or remove any software, and change any system setting. Because root is so powerful, you never use it for everyday tasks. One careless command as root can destroy the entire operating system. Instead, you create ordinary user accounts for daily work and use a tool like sudo to temporarily borrow root power when you need it.

A user account contains several pieces of information stored in the file /etc/passwd. This file lists one line per user, with fields separated by colons. Each line includes the username, a placeholder for the password (the actual password is stored, encrypted, in /etc/shadow), the UID, the primary group ID (GID), the user’s full name (often called the GECOS field), the path to the user’s home directory (usually /home/username), and the user’s default shell (the program that runs when they log in, typically /bin/bash).

Groups are collections of user accounts. A group has a name and a group ID (GID), stored in /etc/group. Every user has a primary group, which is the group that owns any new files the user creates. A user can also belong to supplementary groups, which grant additional permissions. For example, if a file’s permissions allow only members of the “developers” group to edit it, you simply add a user to that group, and they instantly gain the ability to edit that file. This is far easier than changing the file’s permissions for each individual user.

To create a user, you use the command useradd. The simplest form is: - sudo useradd jane

This creates a user “jane” with a UID assigned automatically (usually the next available number, starting from 1000), a primary group also called “jane”, and a home directory /home/jane. If you want more control, you can specify: - sudo useradd -m -u 1050 -g developers -G admin,www-data -s /bin/bash jane

The -m flag creates the home directory if it doesn’t exist. -u sets a specific UID. -g sets the primary group. -G adds supplementary groups. -s sets the shell.

To modify an existing user, you use usermod. For example, to change Jane’s primary group: - sudo usermod -g engineers jane

To add her to a supplementary group without removing her existing ones: - sudo usermod -aG docker jane

The -a flag is crucial: it means “append”. Without it, -G replaces all current supplementary groups with the one you specify — a common trap.

To delete a user, you use userdel. The basic command: - sudo userdel jane

This removes the user from /etc/passwd and /etc/shadow but leaves the home directory and mail spool intact. To also remove the home directory: - sudo userdel -r jane

Be careful: you cannot delete a user while they are logged in or while any process they own is running.

Group management mirrors user management: - groupadd developers — creates a new group. - groupmod -n newname developers — renames the group. - groupdel developers — deletes the group. You cannot delete a group if it is any user’s primary group.

Every piece of information about users and groups is stored in plain text files. You can even edit these files directly using a text editor, though it is safer to use the dedicated commands. The relevant files are: - /etc/passwd — user account information (but not passwords). - /etc/shadow — encrypted passwords and password expiry data. Only root can read this file. - /etc/group — group definitions. - /etc/gshadow — group passwords and group administrator information.

Permissions in Linux are based on three entities: the file’s owner (a user), the file’s group (a group), and everyone else (others). Each entity can have read (r), write (w), and execute (x) permissions. When you create a user and put them in the right groups, you are building the entire access control structure of the system. Without users and groups, every user would be anonymous or, worse, would have to share the root account — which is a catastrophic security risk.

Imagine you work at a medium-sized web development company called Pixelflame. The company has 40 employees, including developers, system administrators, and customer support staff. All of them need access to a shared Linux server that hosts the company’s applications and client data.

Your job as the junior sysadmin is to set up user accounts for all new hires and remove accounts when people leave. You also need to organise access: developers should be able to read and write the source code folders, system administrators need root-level access for server maintenance, and customer support staff should only read certain log files to assist clients.

Here is how you would actually tackle this on a real server:

First, you create three groups: developers, sysadmins, and support. You use: - sudo groupadd developers - sudo groupadd sysadmins - sudo groupadd support

Next, you create the directories where the teams will work (if they don’t already exist): - sudo mkdir /srv/projects /var/log/app /opt/tools

You set the group owner of each directory and adjust the permissions so only members of the appropriate group can access them: - sudo chown root:developers /srv/projects - sudo chown root:sysadmins /opt/tools - sudo chown root:support /var/log/app

Then you set permissions so the group can write to their directory, but others have no access: - sudo chmod 770 /srv/projects (owner and group have full access, others get none) - sudo chmod 770 /opt/tools - sudo chmod 750 /var/log/app (owner and group can read/execute, group can also write, others nothing)

Now a new developer named Alex joins. You create their account: - sudo useradd -m -G developers -s /bin/bash alex

The -G developers flag adds Alex to the supplementary developers group. Because the /srv/projects directory has group ownership set to developers, Alex immediately has full read, write, and execute access to that folder. You don’t need to change any permissions for Alex individually.

Later, the helpdesk support person Rachel needs temporary access to the log files for a client issue. Instead of creating a whole new group or modifying file permissions, you simply add Rachel to the support supplementary group: - sudo usermod -aG support rachel

Rachel can now read /var/log/app without any other changes. This is the power of groups: one command grants access to every resource the group controls.

When a sysadmin named Ben leaves the company, you need to lock him out immediately. You run: - sudo userdel -r ben

This removes Ben’s account and his home directory. But what if Ben had files scattered across the server? His old files will now show a numerical UID instead of a username because the account no longer exists. You should run a find command to locate those files and reassign them to another user: - sudo find / -user ben -exec chown newadmin {} + 2>/dev/null

In real companies, you rarely work alone. You might use a configuration management tool like Ansible or Puppet to create users across hundreds of servers at once. But the underlying commands are the same — useradd, usermod, userdel, groupadd, groupmod, and groupdel — and the LFCS exam expects you to know them cold.