In Linux's multi-user, multi-task environment, user and group management is not "just admin work"— it directly determines who can log in, which processes run under which identities, how the permission model executes, and how sudo privileges are allocated. This post starts from the conceptual model of users and groups (users vs groups, UID/GID meaning and boundaries), systematically organizes commands you'll actually use (useradd/usermod/userdel, groupadd/groupmod/groupdel, passwd/chage), fills in security mechanisms (account locking, password policies, sudo configuration, correct /etc/sudoers syntax), and provides detailed analysis of core system files (/etc/passwd, /etc/shadow, /etc/group, /etc/gshadow, /etc/skel field meanings and practical uses). Finally, it uses practical cases (shared project directories, service account configuration, sudo permission stratification, batch user management) to ground "how to design reasonable user permission schemes" in practice, enabling you to independently complete the full workflow from creating users to permission allocation to security hardening.

Core Linux User and Group Concepts

Relationship Between Users and Groups

Linux is a multi-user system; every user has:

Unique username (like alice, bob)
Unique UID (User ID, numeric identifier)
One primary group (Primary Group, GID)
Zero or more supplementary groups (Supplementary Groups)

Why groups?

Convenient permission management (like "all developers can access /srv/project")
Avoids setting permissions for each user individually (high maintenance cost)

Example:

User alice's primary group is alice (default creates same-name group)
Supplementary groups: developers, docker
This way alice can access resources owned by developers and docker groups

UID and GID Boundaries

UID Range	Purpose	Example
0	Superuser (root)	root
1-999	System users (service accounts, no login allowed)	nginx, mysql, www-data
1000-60000	Normal users (created by admin, login allowed)	alice, bob, charlie

Notes:

CentOS 6 and earlier, normal users start from UID 500
CentOS 7+ and Ubuntu, normal users start from UID 1000

Why distinguish system users and normal users?

System users (like nginx) only run services, don't need login (shell set to /sbin/nologin)
Normal users can log in, run programs, manage files

Core System Files Explained

Linux user information is distributed across several key files:

1. `/etc/passwd` (Public User Database)

Stores all users' basic information, any user can read (but only root can modify).

Format: Each line represents one user, fields separated by colon :

1	username:x:UID:GID:comment:home:shell

Examples:

1 2	testuser:x:1001:1001:Test User:/home/testuser:/bin/bash nginx:x:33:33:nginx user:/var/lib/nginx:/sbin/nologin

Field Explanations:

username: Login name (like testuser)
x: Password placeholder (real password hash in /etc/shadow)
UID: User ID (1001)
- 0: root user
- 1-999: System users (service accounts)
- 1000+: Normal users
GID: Primary group ID (1001)
comment: Comment info (GECOS field, usually user's full name or description)
home: Home directory (/home/testuser)
shell: Login shell (/bin/bash)
- /bin/bash: Login allowed
- /sbin/nologin: Login disabled (commonly used for service accounts)

2. `/etc/shadow` (Password Hashes and Policies)

Stores user password hashes and password expiration policies, only root can read.

Format:

1	username:password_hash:last_change:min:max:warn:inactive:expire:reserved

Example:

1	testuser:$6$4kTxu1...:19103:0:99999:7:::

Field Explanations:

username: Username
password_hash: Password hash
- $6$...: SHA-512 encryption
- $5$...: SHA-256 encryption
- $1$...: MD5 encryption (not recommended)
- ! or *: Account locked
last_change: Date of last password change (days since 1970-01-01)
min: Minimum password age (days, 0 means can change anytime)
max: Maximum password age (days, 99999 means never expires)
warn: Days before password expiration to start warnings
inactive: Days after password expiration before account is disabled
expire: Account expiration date (days since 1970-01-01)
reserved: Reserved field

Common operations:

sudo chage -l testuser  # View user's password policy
sudo chage testuser  # Interactively modify password policy
sudo chage -M 90 testuser  # Set max password age to 90 days
sudo chage -E 2025-12-31 testuser  # Set account expiration date

3. `/etc/group` (Group Information)

Stores all groups' basic information.

Format:

1	groupname:x:GID:member1,member2,member3

Examples:

1 2	developers:x:1001:alice,bob,charlie docker:x:999:alice

Field Explanations:

groupname: Group name (like developers)
x: Group password placeholder (real group password in /etc/gshadow, rarely used)
GID: Group ID (1001)
members: Group member list (comma-separated)

Note:

Member list only includes supplementary group members (not primary group members)
For example, alice's primary group is alice (UID=GID=1001), her supplementary groups are developers and docker, so in /etc/group she only appears in developers and docker member lists

4. `/etc/gshadow` (Group Passwords and Admin Info)

Similar to /etc/shadow, stores group passwords and detailed group management info (used in large companies/complex permission management scenarios).

Format:

1	groupname:password:administrators:members

Example:

1	developers:!::alice,bob,charlie

!: No group password
administrators: Group administrators (can manage group members)
members: Group member list

5. `/etc/skel` (Home Directory Template)

When creating new users, system copies all files from /etc/skel to new user's home directory.

Default contents:

1	ls -la /etc/skel

Example output:

1
2
3

.bashrc
.bash_logout
.profile

Purpose:

Provide unified initial configuration for all new users (like .bashrc, .vimrc, etc.)
Can customize /etc/skel to provide company-wide unified environment configuration

If you created user without home directory before, can manually initialize:

1
2
3

sudo mkdir -p /home/username
sudo cp -r /etc/skel/. /home/username/
sudo chown -R username:username /home/username

User Management Commands

useradd: Create User

Basic usage:

1	sudo useradd testuser

Common parameters:

-m: Auto-create home directory (recommended)
-d PATH: Specify home directory path (default /home/username)
-s SHELL: Specify login shell (like /bin/bash, /bin/zsh, /sbin/nologin)
-g GROUP: Specify primary group (default creates same-name group)
-G GROUPS: Specify supplementary groups (comma-separated, like developers,docker)
-u UID: Specify UID (default auto-assign)
-c COMMENT: Add comment info

Practical examples:

1. Create Normal User

1 2	sudo useradd -m -s /bin/bash alice sudo passwd alice # Set password

1	sudo useradd -r -s /sbin/nologin nginx

-r: Create system user (UID < 1000)

3. Create User with Specified Primary and Supplementary Groups

1 2	sudo useradd -m -g developers -G docker,sudo bob sudo passwd bob

-g developers: Primary group is developers
-G docker,sudo: Supplementary groups are docker and sudo

usermod: Modify User

Basic usage:

1	sudo usermod [options] username

Common parameters:

-l NEWNAME: Modify username
-d PATH: Modify home directory
-m: Use with -d to migrate original home directory contents to new location
-s SHELL: Modify login shell
-g GROUP: Modify primary group
-G GROUPS: Modify supplementary groups (will overwrite existing supplementary groups)
-aG GROUPS: Append supplementary groups (recommended, doesn't overwrite existing)
-L: Lock user (disable password)
-U: Unlock user

Practical examples:

1. Add User to sudo Group

1 2	sudo usermod -aG sudo alice # Debian/Ubuntu sudo usermod -aG wheel alice # CentOS/RHEL

2. Modify User's Shell

1	sudo usermod -s /bin/zsh alice

3. Migrate User Home Directory

1	sudo usermod -d /data/alice -m alice

-d /data/alice: New home directory
-m: Migrate original home directory contents

4. Lock and Unlock User

1 2	sudo usermod -L alice # Lock (adds `!` before password hash in /etc/shadow) sudo usermod -U alice # Unlock

userdel: Delete User

Basic usage:

1 2	sudo userdel testuser # Delete user (keep home directory) sudo userdel -r testuser # Delete user and home directory

Notes:

Before deleting user, confirm no processes are running (ps -u testuser)
After deleting user, files created by that user become "orphaned files" (owner shows as UID, like 1001)

Best practice: Don't directly delete user, lock first

1 2	sudo usermod -L testuser # Lock user (disable login) sudo usermod -s /sbin/nologin testuser # Disable shell

Confirm no issues then delete.

Group Management Commands

groupadd: Create Group

1 2	sudo groupadd developers # Create group sudo groupadd -g 2000 testgroup # Specify GID

groupmod: Modify Group

1 2	sudo groupmod -n newname oldname # Modify group name sudo groupmod -g 3000 developers # Modify GID

groupdel: Delete Group

1	sudo groupdel testgroup

Note: Cannot delete user's primary group (need to delete user first or modify user's primary group).

User-Group Association Operations

Add User to Group

1	sudo usermod -aG groupname username # -a means append (don't overwrite existing supplementary groups)

View User's Groups

1 2	groups username # View all groups user belongs to id username # View user's UID, GID, supplementary groups

Example output:

1	uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(developers),999(docker)

Remove User from Group

1	sudo gpasswd -d username groupname # Remove user from group

Password Management and Security Policies

passwd: Set and Modify Passwords

Basic usage:

1 2	passwd # Modify current user's password sudo passwd username # Modify specified user's password

Advanced usage:

sudo passwd -l username  # Lock user (disable password)
sudo passwd -u username  # Unlock user
sudo passwd -d username  # Delete user password (allow passwordless login, not recommended)
sudo passwd -e username  # Force user to change password on next login

chage: Password Expiration Policy

chage is used to manage user password expiration policies.

View user's password policy:

1	sudo chage -l username

Example output:

Last password change                                    : Jan 28, 2025
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

Common operations:

sudo chage -M 90 username  # Max password age 90 days
sudo chage -m 7 username  # Min password age 7 days (prevent frequent password changes to bypass policy)
sudo chage -W 7 username  # Start warnings 7 days before password expiration
sudo chage -E 2025-12-31 username  # Set account expiration date
sudo chage -I 30 username  # Disable account 30 days after password expiration

Password policy best practices (security hardening):

1	sudo chage -M 90 -W 7 -I 30 username

Max password age 90 days
Start warnings 7 days before expiration
Disable account 30 days after expiration

sudo Permission Configuration

Why Use sudo

Problem: If you log in directly as root:

High risk (one rm -rf / deletes entire system)
Logs can't tell who did what (everything is root)

Solution: Log in as normal user, use sudo when permissions needed.

Advantages:

Logs show which user executed which sudo command
Can limit users to only execute specific commands (like only restart nginx, can't delete files)
Don't need to tell users root password

How sudo Works

User executes sudo command
sudo checks /etc/sudoers file to see if user has permission
If has permission, sudo requires user to enter their own password (not root password)
After verification, execute command as root

Configure sudoers

Config file: /etc/sudoers

Important: Always use visudo to edit (don't directly vim /etc/sudoers)

1	sudo visudo

visudo checks syntax, preventing you from writing errors that completely lock sudo (not even root can fix, only reboot to single-user mode to fix).

Basic format:

1	user host=(runas_user:runas_group) commands

Examples:

1. Give User Full sudo Permissions

1	alice ALL=(ALL:ALL) ALL

First ALL: On all hosts
(ALL:ALL): Can run as any user and group
Last ALL: Can execute any command

2. Give Group Full sudo Permissions

1 2	%sudo ALL=(ALL:ALL) ALL # Debian/Ubuntu (% indicates group) %wheel ALL=(ALL:ALL) ALL # CentOS/RHEL

3. Allow User to Execute Specific Command (No Password)

1	alice ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx

NOPASSWD:: Don't need to enter password
/usr/bin/systemctl restart nginx: Only allow restarting nginx

4. Allow User to Execute Multiple Commands

1	alice ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx

Quick Method: Add to sudo Group

Debian/Ubuntu:

1	sudo usermod -aG sudo alice

CentOS/RHEL:

1	sudo usermod -aG wheel alice

After this, alice can use sudo to execute any command.

Practical Scenarios

Scenario 1: Create Shared Project Directory

Requirement: /srv/project directory, developers group members can all read/write, others cannot access, new files automatically inherit developers group.

Solution:

sudo groupadd developers  # Create group
sudo useradd -m -G developers alice  # Create user and add to group
sudo useradd -m -G developers bob

sudo mkdir /srv/project
sudo chown :developers /srv/project  # Change group to developers
sudo chmod 2770 /srv/project  # SGID + 770

2: SGID (new files automatically inherit developers group)
770: owner and group both rwx, others no permissions

Verification:

1
2
3

su - alice
touch /srv/project/test.txt
ls -l /srv/project/test.txt  # Output: -rw-r--r-- alice developers

Scenario 2: Create Service Account (Like Nginx)

Requirement: Create nginx user for running Nginx service, no login allowed.

Solution:

1	sudo useradd -r -s /sbin/nologin -d /var/lib/nginx -M nginx

-r: Create system user (UID < 1000)
-s /sbin/nologin: Disable login
-d /var/lib/nginx: Specify home directory
-M: Don't create home directory

Scenario 3: Batch Create Users

Suppose you have a user list users.txt:

1
2
3

alice
bob
charlie

Solution:

#!/bin/bash
while read username; do
    sudo useradd -m -s /bin/bash "$username"
    echo "password123" | sudo passwd --stdin "$username"  # CentOS/RHEL
    # Or Ubuntu/Debian:
    # echo "$username:password123" | sudo chpasswd
done < users.txt

Scenario 4: sudo Permission Stratification

Requirement:

alice can execute any command
bob can only restart nginx
charlie can only view logs

Solution: Edit sudo visudo

1
2
3

alice ALL=(ALL:ALL) ALL
bob ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx
charlie ALL=(ALL) NOPASSWD: /usr/bin/tail, /usr/bin/less, /usr/bin/cat

Summary and Further Reading

This article covers the core content of Linux user management: 1. ✅ User and group conceptual model (users vs groups, UID/GID boundaries) 2. ✅ Core system files explained (/etc/passwd, /etc/shadow, /etc/group, /etc/gshadow, /etc/skel) 3. ✅ User management commands (useradd/usermod/userdel, passwd/chage) 4. ✅ Group management commands (groupadd/groupmod/groupdel) 5. ✅ sudo permission configuration (/etc/sudoers, visudo, permission stratification) 6. ✅ Practical scenarios (shared directories, service accounts, batch creation, sudo stratification)

Further Reading:

man useradd: View detailed useradd manual
man sudoers: View detailed sudoers configuration explanation
PAM (Pluggable Authentication Modules): More advanced authentication framework

Next Steps:

《 Linux File Permissions 》: Learn how to manage file/directory permissions (rwx, SUID/SGID, ACL)
《 Linux System Service Management 》: Learn how to manage services, configure auto-start on boot

By this point, you should have upgraded from "can create users" to "can design reasonable user permission schemes, can configure sudo stratified permissions, can manage password policies." User management is the foundation of Linux security; mastering it allows you to better protect systems and data.

Core Linux User and Group Concepts

Relationship Between Users and Groups

UID and GID Boundaries

Core System Files Explained

1. /etc/passwd (Public User Database)

2. /etc/shadow (Password Hashes and Policies)

3. /etc/group (Group Information)

4. /etc/gshadow (Group Passwords and Admin Info)

5. /etc/skel (Home Directory Template)

User Management Commands

useradd: Create User

1. Create Normal User

2. Create Service Account (No Login Allowed)

3. Create User with Specified Primary and Supplementary Groups

usermod: Modify User

1. Add User to sudo Group

2. Modify User's Shell

3. Migrate User Home Directory

4. Lock and Unlock User

userdel: Delete User

Group Management Commands

groupadd: Create Group

groupmod: Modify Group

groupdel: Delete Group

User-Group Association Operations

Add User to Group

View User's Groups

Remove User from Group

Password Management and Security Policies

passwd: Set and Modify Passwords

chage: Password Expiration Policy

sudo Permission Configuration

Why Use sudo

How sudo Works

Configure sudoers

1. Give User Full sudo Permissions

2. Give Group Full sudo Permissions

3. Allow User to Execute Specific Command (No Password)

4. Allow User to Execute Multiple Commands

Quick Method: Add to sudo Group

Practical Scenarios

Scenario 1: Create Shared Project Directory

Scenario 2: Create Service Account (Like Nginx)

Scenario 3: Batch Create Users

Scenario 4: sudo Permission Stratification

Summary and Further Reading

1. `/etc/passwd` (Public User Database)

2. `/etc/shadow` (Password Hashes and Policies)

3. `/etc/group` (Group Information)

4. `/etc/gshadow` (Group Passwords and Admin Info)

5. `/etc/skel` (Home Directory Template)