Users and Groups

Users and Groups in Linux

Linux is a multi-user operating system. Multiple people, applications and
services can operate on the same system while the operating system uses
identities, groups and permissions to determine what each one can access.
Understanding users and groups is therefore essential for both Linux
administration and cybersecurity.

1. What Is a Linux User?

A Linux user is an identity recognized by the operating system. A user can
represent a human administrator, an ordinary employee, a developer, an
application or a background service.

Every Linux user has information associated with the account, including a
username and a numeric user identifier called a UID.

The operating system uses the UID internally when determining ownership and
access. The username is a convenient human-readable representation of that
identity.

2. What Is a UID?

UID means User Identifier. It is a numeric value assigned to
a Linux user account.

For example, a system might contain an account represented conceptually as:

username: student001
UID:      1001

The exact UID ranges and conventions can vary between Linux distributions
and configurations, so administrators should inspect the actual system
rather than assuming that every installation uses identical numbering.

3. What Is a Group?

A group is a collection of users that can be assigned common access
permissions.

Groups make administration easier because an administrator can assign access
to a group instead of configuring every individual user separately.

For example, an organization might create groups such as:

• developers
• analysts
• webadmins
• database
• students

A user’s group membership can affect which files, directories, devices or
services the user can access.

4. GID — Group Identifier

Linux assigns a numeric identifier to groups called a GID,
or Group Identifier.

A file therefore has ownership information that can identify both a user and
a group.

This connects directly to the permissions lesson. Linux can evaluate access
according to the file owner, the owning group and everyone else.

5. The Root Account

The root account is a highly privileged administrative
identity in Linux.

Root can perform operations that ordinary users are not normally permitted to
perform, including many system-administration tasks.

Because excessive privileges increase the possible impact of mistakes or
compromised credentials, security-conscious administrators generally avoid
using unrestricted root access for ordinary daily activities.

6. Why Root Should Be Protected

If an attacker obtains highly privileged credentials, the consequences can
be much greater than compromising an ordinary account.

Good security practice therefore includes:

• Use ordinary accounts for routine activities.
• Use controlled privilege elevation when administrative work is required.
• Protect administrative credentials.
• Enable strong authentication where supported.
• Monitor privileged activity.
• Review administrative access regularly.
• Avoid granting privileges that are not required.

7. Important Linux Account Files

Linux systems commonly maintain account-related information in files under
/etc.

/etc/passwd

The /etc/passwd file contains information about local user
accounts. Despite its historical name, modern Linux systems generally do not
store ordinary plaintext user passwords in this file.

A typical entry contains fields representing information such as the
username, UID, GID, home directory and login shell.

/etc/shadow

The /etc/shadow file is used on many Linux systems for
protected password-related account information. Access to this file is
restricted because it contains sensitive authentication data.

Students should never copy, publish or disclose real password hashes from a
production system.

/etc/group

The /etc/group file contains local group information, including
group names, GIDs and group membership information.

8. Inspecting the Current User

The whoami command displays the current username.

whoami

The id command provides more detailed identity information.

id

A result may show the UID, primary GID and supplementary groups associated
with the current account.

9. Useful User and Group Commands

Common administrative and inspection commands include:

whoami
id
groups
who
w
getent passwd
getent group

These commands can help an administrator understand which accounts exist,
which groups are available and which users are currently associated with a
system.

10. Creating a User

On many Linux distributions, administrators can create users using commands
such as:

sudo useradd -m student001

The exact options and defaults can differ between distributions. The
-m option commonly requests creation of a home directory.

On systems using the adduser utility, an administrator may also
encounter:

sudo adduser student001

Only perform account-creation exercises on systems you administer or on an
authorized training machine.

11. Setting or Changing a Password

The passwd command is commonly used to change a user’s password.
For example:

passwd

An administrator may also manage another account when authorized:

sudo passwd student001

Never use real production credentials in classroom demonstrations.

12. Groups and Group Membership

A user may belong to a primary group and one or more supplementary groups.

Group membership can be inspected using:

groups student001
id student001

Administrators may use tools such as usermod to modify group
membership.

For example, a common pattern is:

sudo usermod -aG developers student001

The -aG pattern is important because the append behavior helps
preserve existing supplementary group membership. Always verify the command
and target account before executing administrative changes.

13. Managing Groups

Common group-management commands include:

groupadd
groupmod
groupdel

For example, creating a training group may look like:

sudo groupadd cybersecurity-lab

Use such commands only in an authorized environment.

14. Sudo and Controlled Privilege

sudo allows authorized users to execute selected commands
with elevated privileges according to the system’s configuration.

Instead of giving every administrator unrestricted root credentials,
organizations can configure controlled administrative access.

A properly designed sudo policy can support:

• Least privilege.
• Accountability.
• Separation of duties.
• Administrative logging.
• Reduced use of unrestricted root sessions.

15. Least Privilege

The principle of least privilege means giving a user,
application or service only the access necessary to perform its legitimate
function.

For example, a web application that only needs to read certain application
files should not automatically receive unrestricted access to the entire
operating system.

Least privilege limits the potential impact of mistakes, vulnerabilities and
compromised accounts.

16. Service Accounts

A service account is an account associated with an application or system
service rather than an ordinary human user.

Examples may include accounts used by web servers, databases or other
background services.

Security practices for service accounts include:

• Give the account only the permissions it needs.
• Avoid unnecessary interactive login access.
• Protect associated credentials or secrets.
• Monitor service activity.
• Review whether the account is still required.
• Document the purpose and owner of the account.

17. Account Lifecycle Management

Accounts should not remain permanently active without a business or
operational reason.

A secure lifecycle commonly includes:

1. Joiner: Create the required account and access.
2. Role change: Review and adjust permissions.
3. Leaver: Disable or remove unnecessary access.
4. Review: Periodically verify that active accounts are still required.

This is especially important when an employee changes department or leaves an
organization.

18. Disabled and Unused Accounts

Unused accounts can create unnecessary attack surface.

Organizations should have documented procedures for disabling or removing
accounts that are no longer required.

Care must be taken with service accounts because removing an account without
understanding its purpose can interrupt legitimate services.

19. Authentication and Authorization

Two important security concepts are:

• Authentication: Verifying who a user or system is.
• Authorization: Determining what that identity is allowed to do.

A successful login does not automatically mean that the user should have
access to every resource on the system.

20. Users, Groups and File Permissions

Linux file permissions connect users and groups directly to access control.

Consider:

-rw-r-----  student001  developers  report.txt

Conceptually, the permissions describe what the owner, members of the
associated group and other users can do.

Therefore, user and group administration should always be considered together
with file and directory permissions.

21. Security Risks Related to Users and Groups

Poor account management can create vulnerabilities such as:

• Unnecessary administrative accounts.
• Excessive group membership.
• Shared personal accounts.
• Inactive accounts that remain enabled.
• Unnecessary sudo privileges.
• Over-privileged service accounts.
• Weak authentication controls.
• Unmonitored privileged activity.

22. Account Auditing

Account auditing involves reviewing who has access and whether that access
remains appropriate.

Useful questions include:

• Which users exist?
• Which users are administrators?
• Which groups have sensitive privileges?
• Which accounts are inactive?
• Which service accounts exist?
• Which accounts can use sudo?
• Are former users still enabled?

23. Security Monitoring

Authentication and authorization events can provide valuable information
during security investigations.

Depending on the Linux distribution and configuration, authentication
information may be available through system logs, journald or files such as
authentication-related log files under /var/log.

Investigators should follow the logging configuration of the specific system
rather than assuming that every Linux distribution stores events in exactly
the same location.

24. A Cybersecurity Investigation Example

Imagine that an organization notices unexpected access to a sensitive
application.

An analyst might investigate:

1. Which account performed the activity?
2. What groups did the account belong to?
3. Did the account have elevated privileges?
4. Was the account expected to access the resource?
5. Were there unusual authentication events?
6. Was the account recently created or modified?
7. Was the account supposed to remain active?

The goal is not to blame a person based on a single event. Analysts should
correlate authentication logs, access records, system changes and other
available evidence.

25. Safe Laboratory Exercise

Create a Linux virtual machine or another authorized training environment.
Do not perform these exercises on systems you do not administer.

Exercise:

1. Check your current username with whoami.
2. Display your UID and groups with id.
3. Inspect group membership.
4. Create a temporary laboratory user.
5. Create a temporary laboratory group.
6. Add the laboratory user to the group.
7. Verify the membership.
8. Inspect the user’s home directory.
9. Review the relationship between the user’s identity and file ownership.
10. Remove or disable the laboratory account when finished.

26. PHP Example — Synthetic Account Risk Review

The following example demonstrates the logic of reviewing account properties
using synthetic data. It does not inspect or modify real Linux accounts.

<?php

$account = array(
    'username'          => 'student001',
    'uid'               => 1001,
    'group_count'       => 3,
    'is_root'           => false,
    'sudo_access'       => false,
    'mfa_enabled'       => true,
    'account_locked'    => false,
    'service_account'   => false,
);

$risk_flags = array();

if ( $account['is_root'] ) {
    $risk_flags[] = 'Review direct root-account usage.';
}

if ( $account['sudo_access'] ) {
    $risk_flags[] = 'Confirm that elevated access is required.';
}

if ( $account['group_count'] > 8 ) {
    $risk_flags[] = 'Review excessive group membership.';
}

if ( ! $account['mfa_enabled'] ) {
    $risk_flags[] = 'MFA is not enabled.';
}

if ( $account['account_locked'] ) {
    $risk_flags[] = 'Account is currently locked.';
}

if ( empty( $risk_flags ) ) {

    echo 'No synthetic account-risk indicators detected.';

} else {

    echo implode(
        '<br>',
        array_map( 'esc_html', $risk_flags )
    );
}

27. Important Security Principle

Users and groups are not merely administrative concepts. They are part of
the security boundary of a Linux system.

A compromised ordinary account with limited permissions may have a smaller
impact than a compromised privileged account. Good identity and access
management therefore reduces the potential impact of security incidents.

28. Practical Assignment

In an authorized Linux virtual machine, create a short report containing:

1. The current user and UID.
2. The primary group and supplementary groups.
3. The difference between a normal user and root.
4. The purpose of /etc/passwd, /etc/shadow and /etc/group.
5. The purpose of sudo.
6. Three examples of least-privilege controls.
7. Two security risks caused by unnecessary accounts.
8. One example of a service account.

29. Review Questions

1. What is a Linux user?
2. What does UID mean?
3. What does GID mean?
4. What is the purpose of a Linux group?
5. Why is the root account highly sensitive?
6. What is sudo used for?
7. What is least privilege?
8. What is a service account?
9. Why should inactive accounts be reviewed?
10. How can user and group management affect file permissions?
11. Why is account lifecycle management important?

30. Key Takeaways

• Linux is designed to support multiple users and services.
• Users are identified internally by UIDs.
• Groups use GIDs and simplify access management.
• Root has extensive administrative privileges.
• sudo can provide controlled privilege elevation.
• Service accounts should have only the permissions they require.
• Unused accounts increase unnecessary attack surface.
• Regular access reviews help maintain least privilege.
• Authentication logs can help investigate suspicious account activity.
• User and group management is a fundamental part of Linux cybersecurity.

Conclusion

Understanding Linux users and groups gives cybersecurity students a strong
foundation for access control, system administration and incident
investigation. The next lesson will examine how Linux manages running
programs and background services through Processes.