Linux Users & Groups Deep Administration Guide

A production-grade, systems-level guide to Linux users, groups, and identity management. This document does not repeat basic commands only—it explains how Linux models identities internally, how permissions are enforced, how administrators design group strategies, and how everything ties into security, filesystems, and enterprise setups.

Why Users & Groups Exist

Linux is designed as a multi-user, time-sharing operating system.

Goals:

• Isolate users from each other

• Prevent accidental or malicious damage

• Enable controlled collaboration

Everything in Linux runs as a user, even system services.

Identity Model in Linux

Core Identifiers

Example:

id

UIDs are what the kernel actually checks, not usernames.

System vs Normal Users

System users cannot usually log in.

Where Linux Stores User Data

Key Files

Never edit /etc/shadow manually.

Authentication vs Authorization

Linux users & groups control authorization, not authentication mechanisms.

User Management (deep Dive)

Creating Users (low-level)

sudo useradd -m -s /bin/bash alice

Key options:

• -u → UID

• -g → primary group

• -G → supplementary groups

• -d → home directory

Passwords:

sudo passwd alice

Modifying Users

sudo usermod -s /bin/zsh alice
sudo usermod -aG sudo alice

⚠ -G replaces existing groups — always use -aG.

Deleting Users Safely

sudo userdel alice
sudo userdel -r alice

Check for remaining files:

find / -uid 1001

Group Management (deep Dive)

Creating Groups

sudo groupadd developers

Modifying Groups

sudo gpasswd -a alice developers
sudo gpasswd -d alice developers

Groups enable permission abstraction.

Primary vs Supplementary Groups (deep Truth)

Primary Group

• Exactly one per user

• Stored in /etc/passwd

• Default group for new files

Supplementary Groups

• Multiple allowed

• Stored in /etc/group

• Grant additional access

Changing behavior with setgid.

Useradd vs Adduser (truth Table)

Admins prefer useradd in scripts, adduser on desktops.

Group-based Access Control (patterns)

Pattern 1: Project Group

projectA → groupA

Benefits:

• No per-user permissions

• Easy onboarding/offboarding

Pattern 2: Role-based Groups

sudo, docker, admins

Assign roles instead of permissions.

File Ownership & Permission Resolution

Resolution order:

1. Owner

2. Group

3. Others

Kernel checks IDs, not names.

Example:

ls -l file

Setgid, Umask & Collaboration

Setgid Directory

chmod g+s /shared

Effect:

• New files inherit group

Umask

umask 002

Ensures group write access.

Advanced Permission Scenarios

Shared Development Folder

groupadd dev
chown :dev /project
chmod 2775 /project

Prevents permission conflicts.

Auditing & Troubleshooting

Key commands:

id user
groups user
getent passwd
group user

Find access failures:

namei -l path

Security Best Practices

• Use groups, not users

• Avoid root where possible

• Remove users cleanly

• Audit group membership regularly

Avoid permission creep.

Enterprise & Server Scenarios

• LDAP / Active Directory

• Centralized identity

• sudo via group policy

Local users become identity clients.

Hands-on Labs

Beginner:

id

Intermediate:

mkdir /shared
chmod 2770 /shared

Advanced:

find / -gid dev

✅ This guide is written for Linux administrators, security engineers, DevOps, and embedded Linux developers.

Understanding users and groups means understanding Linux security itself.

Happy administering 🐧🔐