Unit 7: User and Group Administration

Linux is a multi-user operating system in which every process, file and login is owned by a numeric identity, and administration means creating, modifying and retiring those identities safely. This unit covers the account and group model and the standard command-line tools (shadow-utils) that manipulate it. All commands shown require root privileges, usually via sudo.

• User (UID): A numeric User ID mapped to a login name; UID 0 is root, 1–999 are reserved for system/service accounts, and 1000+ are regular human users on most distributions.
• Group (GID): A numeric Group ID that lets several users share access to files and resources under one set of permissions.
• Primary group: The single group recorded in a user's account entry; new files the user creates take this group by default.
• Supplementary groups: Additional groups a user belongs to for extra access (e.g. sudo, wheel, docker).
• Backing files: Account data lives in flat text databases — /etc/passwd, /etc/shadow, /etc/group, /etc/gshadow — read on every login and permission check.

II. User Accounts and Groups

The identity model that all the tools operate on.

A. Types of accounts

Not every account represents a person.

• Root (superuser): UID 0, bypasses all permission checks; used only for administration.
• System accounts: UID 1–999, own daemons and services (www-data, sshd, mail); usually have no login shell and no password login.
• Regular users: UID ≥ 1000, interactive humans with a home directory and login shell.

B. Primary versus supplementary groups

A user's group memberships are split into two roles.

1. Primary group: Exactly one, stored in the fourth field of the /etc/passwd line as a GID; determines the group ownership of newly created files. Many systems create a private group with the same name as the user (User Private Group scheme).
2. Supplementary groups: Zero or more, stored as member lists in /etc/group; grant additional access without changing file-creation defaults.

• Inspecting membership: id username prints uid=1001(anil) gid=1001(anil) groups=1001(anil),27(sudo), showing UID, primary GID and all supplementary groups.

III. useradd

Creating a new user account.

A. Purpose and syntax

useradd writes a new entry into the account files and, with the right flag, provisions a home directory.

useradd [options] username

• -m: Create the home directory (e.g. /home/anil) and copy skeleton files from /etc/skel.

• -d /path: Set a custom home directory path.

• -s /bin/bash: Set the login shell; /usr/sbin/nologin blocks interactive login.

• -u 1500: Force a specific UID instead of the next free one.

• -g developers: Set the primary group (must already exist).

• -G sudo,docker: Add supplementary groups (comma-separated, no spaces).

• -c "Full Name": Set the comment/GECOS field.

• Defaults source: Values not given on the command line come from /etc/default/useradd and /etc/login.defs (UID range, default shell, mail spool).

Worked example — a full interactive user:

useradd -m -s /bin/bash -c "Anil Kumar" -G sudo anil
passwd anil

This creates the account, home directory and bash shell, adds Anil to sudo, then sets an initial password (the account stays locked until a password exists).

IV. userdel

Removing a user account.

A. Purpose and syntax

userdel deletes the account's entries from /etc/passwd, /etc/shadow and its group memberships.

userdel [options] username

• No flag: Removes the account entry only; the home directory and its files remain (now owned by an orphaned UID).

• -r: Removes the home directory and mail spool along with the account.

• -f: Force removal even if the user is logged in or files are in use — a destructive last resort.

• Caution: Files elsewhere on the system owned by the deleted UID keep that number; a future user reusing the UID inherits those files. Locate them first with find / -uid <old-uid>.

V. usermod

Modifying an existing user account.

A. Purpose and syntax

usermod edits fields of an account already present in /etc/passwd//etc/shadow.

usermod [options] username

• -l newname: Rename the login (does not rename the home directory).
• -d /new/home -m: Change the home directory and move existing contents into it.
• -s /bin/zsh: Change the login shell.
• -g newgroup: Change the primary group.
• -L / -U: Lock / unlock the account by disabling or restoring the password.

B. Adding supplementary groups safely

The append flag is the common source of error.

1. Overwrite (wrong for adding): usermod -G docker anil replaces the entire supplementary list, silently dropping the user from every other group.
2. Append (correct): usermod -aG docker anil uses -a with -G to add without removing existing memberships.

• Effect timing: New group membership takes effect at the user's next login, not in the current shell session.

VI. groupadd

Creating a new group.

A. Purpose and syntax

groupadd adds a new entry to /etc/group (and /etc/gshadow).

groupadd [options] groupname

• -g 1600: Assign a specific GID instead of the next free one.

• -r: Create a system group (GID from the reserved low range) for a service.

• Example: groupadd -g 2000 developers creates a shared group so several users can be granted common access to a project directory.

VII. groupdel

Removing a group.

A. Purpose and syntax

groupdel removes a group entry from /etc/group.

groupdel groupname

• Primary-group protection: A group cannot be deleted while it is still the primary group of any existing user; reassign those users' primary group first with usermod -g.
• Effect: Supplementary references to the group vanish, but files on disk still carry the now-unallocated GID until reassigned with chgrp.

VIII. groupmod

Modifying an existing group.

A. Purpose and syntax

groupmod changes a group's name or GID.

groupmod [options] groupname

• -n newname: Rename the group; the GID and all file ownerships by number are unaffected.
• -g 2500: Change the numeric GID; files previously owned by the old GID are not automatically updated and may need chgrp.

IX. Password Management

Setting, ageing and locking credentials.

A. Setting passwords

Passwords are never stored in /etc/passwd; they live hashed in /etc/shadow.

• passwd username: Sets or changes a user's password; run without an argument it changes the caller's own.
• Hashing: The stored value is a salted hash (typically SHA-512, prefix $6$), so the plaintext cannot be recovered from the file.
• Locking: passwd -l anil prepends ! to the hash to disable login; passwd -u anil reverses it.

B. Password ageing

The chage command controls the lifetime of a credential.

• -M 90: Maximum days a password stays valid before a forced change.
• -m 7: Minimum days between changes.
• -W 7: Days of warning before expiry.
• -l anil: List the current ageing settings for a user.
• Force change: chage -d 0 anil expires the password immediately, requiring a reset at next login.

X. Important Files: /etc/passwd and /etc/group

The plain-text account and group databases.

A. /etc/passwd

Each line is one account, seven colon-separated fields.

anil:x:1001:1001:Anil Kumar:/home/anil:/bin/bash

• Field 1 — username: The login name.
• Field 2 — password placeholder: x means the hash is in /etc/shadow; historically the hash sat here.
• Field 3 — UID: Numeric user ID.
• Field 4 — GID: Primary group ID.
• Field 5 — GECOS: Comment / full name.
• Field 6 — home directory: Working directory at login.
• Field 7 — shell: Program run at login; /usr/sbin/nologin denies interactive access.
• Permissions: World-readable (644) because many programs resolve UID-to-name; this is safe only because the hashes moved to the root-only /etc/shadow.

B. /etc/group

Each line is one group, four colon-separated fields.

developers:x:2000:anil,ravi

• Field 1 — group name: Human-readable label.
• Field 2 — password placeholder: x; group passwords (rarely used) live in /etc/gshadow.
• Field 3 — GID: Numeric group ID.
• Field 4 — member list: Comma-separated users for whom this is a supplementary group; a user's primary group need not appear here.
• Consistency: The GID in this file must match the primary GID referenced in /etc/passwd; editing by hand risks orphaning that link, which is why vipr/vigr lock the files during edits.