Linux · Lesson 03
Users, Groups & Sudo Privilege
Review Linux identities, group membership, sudo privilege, account state, shells, home directories, and service dependencies without deleting legitimate users or breaking required services.
Identity is one of the highest-impact areas in a competition image. The goal is not to remove every unfamiliar account. The goal is to understand who or what the account represents, compare that evidence to the scenario, and correct only the confirmed mismatch.
Lesson Snapshot
Learning objectives
What identity review should help you decide
Explain how Linux users, groups, UIDs, GIDs, shells, and home directories fit together.
Distinguish normal human accounts, service accounts, system accounts, and privileged identities before making changes.
Inspect sudo access through groups and sudoers configuration without assuming one administrative model everywhere.
Use read-only commands to inventory users, groups, login shells, account status, and administrative privilege.
Correct unnecessary privilege with the least disruptive change while preserving required accounts and services.
Verify identity changes from both the account and authorization perspective.
Core idea
Fix the privilege problem, not the person
An authorized user can still have the wrong privilege. If Avery is supposed to be a standard user but appears in sudo, the correct response may be to remove unnecessary administrative membership while keeping Avery's account and required access intact.
Identity risk
Unfamiliar does not mean unauthorized
Linux systems contain package-created users, service identities, application accounts, and system accounts. Removing one without evidence can break a required service even when no human ever logs in as that account.
Identity fundamentals
Six concepts behind Linux accounts and groups
User account
A Linux user is an identity represented by a username and numeric UID. Human users, services, daemons, and system components can all have accounts.
Primary group
Each user has a primary group identified by a GID. New files commonly inherit that group unless another mechanism changes it.
Supplementary groups
A user can belong to additional groups that grant access to files, devices, services, administrative functions, or applications.
Login shell
The shell field can indicate whether an account is intended for interactive login, although shell value alone does not prove whether an account is legitimate or currently usable.
Home directory
A home directory commonly stores user files, shell configuration, SSH material, application settings, and other identity-specific data.
Privilege
Administrative capability can come from sudo configuration, group membership, direct sudoers rules, root access, setuid programs, service context, or other mechanisms.
Important identity files
Know what each source tells you
/etc/passwdStores account records including username, UID, primary GID, home directory, and login shell. Password hashes are not normally stored here on modern Ubuntu-family systems.
Caution
Do not delete lines manually unless you fully understand the effect. Prefer account-management tools for controlled changes.
/etc/shadowStores password hashes and password-aging metadata for local accounts.
Caution
Highly sensitive. Requires elevated access. Avoid exposing or copying password hashes unnecessarily.
/etc/groupStores local group definitions and supplementary membership information.
Caution
Direct edits can create malformed group configuration. Use group-management tools where practical.
/etc/gshadowStores protected group information and administrative metadata.
Caution
Treat as privileged identity data.
/etc/sudoersPrimary sudo policy file controlling who may run commands with elevated privilege.
Caution
Syntax errors can break sudo access. Use visudo when editing.
/etc/sudoers.d/Drop-in directory for additional sudo rules.
Caution
A user may have privilege here even if they are not in the sudo group.
/etc/passwd anatomy
Read the account record before making a judgment
morgan:x:1001:1001:Morgan Lee:/home/morgan:/bin/bashUsername
morganHuman-readable account name used for login and ownership display.
Password placeholder
xUsually indicates password data is stored in /etc/shadow rather than /etc/passwd.
UID
1001Numeric user identity used internally by Linux for ownership and access decisions.
Primary GID
1001Numeric identifier of the user's primary group.
Comment / GECOS
Morgan LeeDescriptive account information. It is not a security control.
Home directory
/home/morganDefault location for the user's personal files and user-level configuration.
Login shell
/bin/bashProgram started for an interactive shell login when applicable.
Do not use the shell field as your only decision
A non-interactive shell can be completely appropriate for a service account, while an interactive shell can be legitimate for a human user. The scenario and supporting evidence determine whether the account belongs.
Account classification
Human, service, system, or unknown?
Human administrator
Common signs
Named in the scenario, interactive shell, home directory, approved sudo access, expected login activity.
Caution
Do not remove required privilege just because the account looks powerful; compare it to the scenario first.
Human standard user
Common signs
Named in the scenario, normal home directory, interactive shell, no unnecessary administrative privilege.
Caution
A legitimate user with excess privilege may need a group correction, not account deletion.
Service account
Common signs
Often tied to an application or daemon, may have a non-interactive shell, special home or data directory, and ownership of service files.
Caution
Disabling it can break the service. Confirm package, process, file ownership, and service dependencies.
System account
Common signs
Often created by the operating system or packages, may have low UID values or non-login shells, and may not represent a person.
Caution
System-account ranges and conventions vary. Do not use UID alone as a deletion rule.
Unknown account
Common signs
Not clearly explained by the scenario, package inventory, service role, or system purpose.
Caution
Unknown means investigate. Check UID, groups, shell, home, files, processes, sudo access, logs, and package relationships before action.
Inspection-first identity review
Commands that describe accounts before you change them
getent passwdList account records through the system account database.
getent passwd usernameInspect one account record.
id usernameShow the user's UID, primary GID, and supplementary groups.
groups usernameShow group membership for a user.
getent groupList groups known through the system group database.
getent group sudoInspect members of the sudo group on systems that use it for administration.
sudo -l -U usernameReview sudo privileges for a specific user when permitted.
sudo visudo -cValidate sudoers syntax without changing policy.
sudo passwd -S usernameShow local password status information for an account.
lastlogShow last-login information where available. Treat it as one indicator, not perfect forensic truth.
Sudo privilege
Administrative access is more than one group
sudo group
Ubuntu and Linux Mint commonly grant broad administrative sudo access through membership in the sudo group.
Direct sudoers rule
A user can receive sudo privilege directly through /etc/sudoers or a file under /etc/sudoers.d/ without belonging to the sudo group.
Command-limited privilege
sudoers can allow only certain commands rather than unrestricted root-equivalent access.
NOPASSWD
A sudo rule can permit commands without prompting for the user's password. Whether that is appropriate depends on the scenario and system role.
Run-as targets
sudo rules can allow commands as root or another account. Do not assume every rule means unrestricted root access.
Configuration precedence
Multiple sudoers files and rules can interact. Inspect the effective result rather than assuming one file tells the whole story.
Practical review order
Scenario comparison
Compare identities to the mission
Account
Morgan
Scenario
Authorized administrator
Observed
UID 1001, interactive shell, member of sudo, normal home directory.
Decision
Likely appropriate. Verify sudo rules and retain required privilege.
Account
Avery
Scenario
Authorized standard user
Observed
UID 1002, interactive shell, unexpectedly member of sudo.
Decision
High-confidence privilege mismatch. Preserve account and remove only unnecessary administrative membership after verification.
Account
Riley
Scenario
Authorized standard user
Observed
UID 1003, interactive shell, no sudo access.
Decision
Likely appropriate. Verify required application and file access rather than changing the account.
Account
backupsvc
Scenario
Not named
Observed
Non-interactive shell, owns backup data, referenced by a systemd backup service.
Decision
Do not disable based only on the name. Treat as a likely service identity and investigate dependency before change.
Account
guest-temp
Scenario
Not authorized
Observed
Interactive shell, home directory, no clear package or service relationship.
Decision
Investigate login activity, files, groups, and evidence. If confirmed unauthorized, disable or remove using the least disruptive scenario-appropriate action.
Controlled identity changes
Change the smallest thing that solves the confirmed problem
Goal
Remove a user from the sudo group
Example command
sudo gpasswd -d username sudoUse carefully
Use only when the scenario confirms the user should remain a normal account but should not have sudo-group privilege.
Goal
Add an authorized administrator to sudo
Example command
sudo usermod -aG sudo usernameUse carefully
Use only when the scenario clearly requires the account to have administrative privilege. Verify afterward.
Goal
Lock a local account password
Example command
sudo passwd -l usernameUse carefully
Locking the password does not necessarily stop every access path. SSH keys, existing sessions, cron, services, or other mechanisms may still use the account.
Goal
Unlock a local account password
Example command
sudo passwd -u usernameUse carefully
Use only when the account is authorized and the scenario requires password authentication.
Goal
Disable interactive shell access
Example command
sudo usermod -s /usr/sbin/nologin usernameUse carefully
Changing the shell can affect legitimate scripts or services. Confirm account purpose first.
Goal
Validate sudoers configuration
Example command
sudo visudo -cUse carefully
Validation is a safe checkpoint before relying on a sudoers edit.
Permanent deletion should not be the first reflex
When evidence is incomplete, a reversible containment action such as correcting privilege or locking an unauthorized human account may preserve more evidence and create less risk than immediate deletion. The correct action still depends on the scenario.
Root review
Understand UID 0
Root is UID 0
Linux treats UID 0 as superuser privilege. The username is commonly root, but UID is the critical identity attribute.
Do not create extra UID 0 accounts
An unexpected account with UID 0 deserves immediate investigation because it has root-equivalent identity.
Root login policy is contextual
Interactive root login, SSH root login, and sudo-based administration are separate questions. Review the scenario and configuration rather than using one universal rule.
sudo activity can be evidence
Authentication and journal logs may help show which user invoked sudo and what happened around that time.
An unexpected UID 0 account deserves high-priority investigation, but preserve evidence and understand the account before taking a destructive action.
Identity evidence
Build decisions from more than one source
Account database
getent passwd usernameUID, primary group, home, shell, and basic account record.
Group membership
id usernameEffective user/group identity and supplementary groups.
Sudo policy
sudo -l -U usernameEffective sudo permissions when the system allows the query.
Password status
sudo passwd -S usernameLocal password-state metadata such as whether a password is locked.
Authentication logs
sudo journalctl _COMM=sudo --since todayRecent sudo-related journal entries where available.
Login history
lastRecorded login sessions from wtmp data where present.
Last login indicator
lastlogLast-login record for accounts where available. Not complete proof of account legitimacy or use.
Common mistakes
Identity shortcuts that create bigger problems
Deleting a legitimate user because privilege is wrong
If the account is authorized but should not be an administrator, correct the privilege instead of removing the identity.
Using UID alone to identify service accounts
UID ranges vary by system and package. Combine UID with shell, home, package, service, process, and ownership evidence.
Checking only the sudo group
Direct sudoers rules can grant privilege even when the user is not in the sudo group.
Giving sudo to fix an access problem
Administrative privilege is not a substitute for correct file, group, service, or application permissions.
Assuming a locked password disables the account completely
Other authentication methods, existing sessions, SSH keys, services, and scheduled execution may still matter.
Editing /etc/sudoers with a normal text editor
A syntax error can break sudo. Use visudo for validation and controlled editing.
Verification
Prove the identity state after every privilege change
Identity
Run id username and confirm UID, primary group, and supplementary groups match the intended role.
Sudo access
Run sudo -l -U username when permitted and confirm the effective administrative privilege is correct.
Account state
Use passwd -S and relevant login configuration to confirm the intended password or account state.
Required login
Confirm authorized users can still access the system through the scenario-required method.
Service dependency
If the account is tied to a service, verify that service and owned files still function.
Evidence
Confirm logs and account evidence needed for forensics were preserved before remediation.
Defensive lab
Audit a fictional Linux identity set
Read the fictional scenario: Morgan is the only administrator; Avery and Riley must remain standard users; an internal backup service must remain functional.
Run getent passwd, getent group sudo, id for the named users, and sudo privilege checks where permitted.
Classify Morgan, Avery, Riley, backupsvc, and guest-temp using scenario evidence, shells, groups, homes, services, and login information.
Identify Avery's unnecessary sudo-group membership as a privilege problem without deleting Avery.
Investigate backupsvc before changing it by checking its service relationship, file ownership, and process context.
If guest-temp is confirmed unauthorized after evidence review, choose a reversible containment action before permanent removal where practical.
Re-run id, groups, sudo privilege checks, required logins, and the backup service verification after changes.
Lesson checklist
Before moving on
I can explain UID, GID, primary groups, supplementary groups, shells, and home directories.
I can read a basic /etc/passwd record without confusing the password placeholder with the actual password hash.
I know where /etc/shadow, /etc/group, /etc/sudoers, and /etc/sudoers.d/ fit into identity review.
I compare users and administrators to the scenario before changing them.
I do not classify accounts using UID or username alone.
I check both sudo-group membership and direct sudoers rules.
I understand that service accounts can be required even when they are not named in the scenario.
I correct excessive privilege without deleting legitimate users.
I validate sudoers syntax with visudo.
I verify identity, privilege, login, services, and evidence after changes.
Reflection
Check your reasoning
Question 1
Why is a legitimate standard user in sudo different from an unauthorized user account?
Question 2
Why can a service account with a non-interactive shell still be essential?
Question 3
Why is checking only getent group sudo insufficient for a complete privilege review?
Question 4
What additional evidence would you collect before disabling an unfamiliar account?
Question 5
Why does locking a password not always disable every way an account can be used?
Question 6
What should you verify after changing a user's administrative privilege?
Carry this forward
Identity review is about authorization and purpose. Keep required users and services, remove unnecessary privilege, investigate unknown identities, and verify the effect of every change.