Users and Groups

Linux uses user and group identities to label processes, own filesystem objects, and make access-control decisions. Human-readable names help administrators, while the kernel primarily works with numeric identifiers and process credentials.

Identifying Users with UIDs

Each account has a numeric user ID, or UID. Usernames map to UIDs through the system's account databases. Files store numeric ownership, which tools normally display as a corresponding name.

Run id to inspect the current process identity information:

$ id
uid=1000(alice) gid=1000(alice) groups=1000(alice),27(sudo)

Values differ by system. Human login accounts commonly have home directories such as /home/alice, but accounts can use another path or no ordinary home at all. Service accounts often exist to run software with limited identity rather than to support interactive login.

Organizing Access with Groups

A group has a numeric group ID, or GID. An account normally has one primary group and can belong to supplementary groups. Group membership lets administrators grant access to a set of users without assigning permissions one account at a time.

Inspect memberships with:

$ id alice
$ groups alice

These commands report configured or resolved identity information. Directory services and caches can participate, so directly reading /etc/group does not always show the complete effective membership picture.

Understanding Process Credentials

A process has credentials such as real and effective UIDs and GIDs plus supplementary groups. The effective credentials are central to many permission checks. A process started by a user usually inherits credentials from its parent, but controlled mechanisms can change them.

This is more precise than saying a process always runs only “as the user who started it.” Set-user-ID executables, service managers, containers, namespaces, and privilege-changing system calls can affect the identities visible or effective in a particular context.

Recognizing the Root Identity

The account traditionally named root has UID 0. UID 0 is treated specially by many Linux permission mechanisms and carries broad administrative power. Modern Linux can also divide privileges through capabilities, namespaces, mandatory access controls, and service confinement, so “unlimited power in every context” is an oversimplification.

Routine work should use an unprivileged account. Administrative authority increases the impact of path mistakes, untrusted commands, and compromised software.

Using sudo under a Policy

sudo asks its configured policy whether the invoking user may run a command as a target user. The default target is often root, but a policy or -u USER can select another account. Authentication prompts and logging also depend on configuration.

List the commands the current account is allowed to run:

$ sudo -l

Only use an allowed administrative command when the task requires it and you understand its effects. Do not use sudo merely to silence a permission error, and do not display password-hash databases such as /etc/shadow as a casual exercise.

To practice account and group administration in a controlled environment, try these hands-on labs:

1. Manage Linux User Accounts with useradd, usermod, and userdel - Practice the complete lifecycle of user administration, from creating and securing new accounts to modifying and deleting them.
2. Manage Linux Groups with groupadd, usermod, and groupdel - Gain hands-on experience with core command-line utilities for group administration, including creating new groups, modifying user memberships, and removing groups.
3. Configure User Accounts and Sudo Privileges in Linux - Learn essential techniques for managing user accounts and sudo privileges to enhance the security of a Linux system, including granting administrative permissions.

Summary

You can now describe how Linux represents identities and delegates administrative commands.

1. Identify accounts by UID and groups by GID.
2. Distinguish primary and supplementary group membership.
3. Relate process credentials to access checks.
4. Recognize UID 0 as the traditional root identity.
5. Treat sudo as a policy-controlled delegation tool.