High School IntermediateModule I2Lesson 3 of 8

I2.3 Users, Groups, and Permissions

Analyze fictional Linux identities, group memberships, file ownership, read-write-execute permissions, service accounts, temporary access, and least-privilege decisions.

Previous LessonBack to ModuleNext Lesson

Lesson Progress

Users, Groups, and Permissions

High School Intermediate • I2: Linux Basics for Security • Lesson 3 of 8

38% complete

Readiness Check

Before You Start

0/5 ready

Professional Hook

Access Can Be Technically Valid and Still Be Too Broad, Stale, or Unowned

A user may belong to a group because of an old project. A service account may own files outside its approved application. A directory may grant write access to every local user because it was convenient during setup. Defenders compare the current technical state with role, ownership, sensitivity, duration, dependency, and least privilege.

Weak response

“The permission works, so leave it unchanged.”

Strong response

“Confirm the identity, role, groups, ownership, effective access, business need, sensitivity, duration, and dependencies before recommending the narrowest safe access.”

Objective 1

Explain Linux users, groups, ownership, primary groups, supplementary groups, and least-privilege access.

Objective 2

Interpret symbolic permission strings for owner, group, and others without changing real systems.

Objective 3

Connect account and permission evidence with approved roles, service needs, file sensitivity, and business purpose.

Objective 4

Identify broad, stale, inherited, temporary, shared, and review-required access patterns.

Objective 5

Recommend authorized permission corrections with dependency review, validation, rollback, and documentation.

Why This Matters

Identity and Permission Errors Can Expose Data or Break Services

Overly broad access may expose sensitive files, while overly narrow access may interrupt an approved application. Strong defenders balance confidentiality, integrity, availability, accountability, ownership, and operational dependencies.

Account Types

Different Identities Need Different Controls

Standard user

Supports normal interactive work with limited access to approved files, applications, and groups.

Defensive controls: Named ownership, strong authentication, limited groups, no unnecessary elevation, review on role changes.

Administrator

Performs approved system management and security tasks.

Defensive controls: Named account, MFA where supported, separate standard account, limited use, logging, and periodic review.

Service account

Runs one approved application, daemon, automation, or integration.

Defensive controls: Noninteractive when possible, narrow permissions, owned by a team, rotated credentials, monitored use.

Shared account

Sometimes used by legacy systems or controlled operational workflows.

Defensive controls: Avoid where possible; require documented owner, approved purpose, compensating logging, and retirement plan.

Temporary account

Supports time-limited maintenance, testing, training, or vendor work.

Defensive controls: Approval, expiration date, limited groups, activity logging, and confirmed removal or disablement.

Disabled or retired account

Preserves historical ownership or audit context after active use ends.

Defensive controls: No login, reviewed group memberships, transferred ownership, documented retention, and eventual cleanup.

Permission Reading

Interpret Owner, Group, and Other Access

rwx------

The owner can read, write, and execute; group and others have no access.

Appropriate for highly private user or administrative content when the owner requires full control.
rw-r-----

The owner can read and write; the group can read; others have no access.

Useful for confidential team files where the owner edits and an approved group reviews.
rwxr-x---

The owner has full access; the group can read and traverse; others have no access.

May fit a shared service directory when group members need controlled use but not modification.
rw-rw----

The owner and group can read and write; others have no access.

May fit collaborative team files when group membership is tightly governed.
rwxrwxrwx

Owner, group, and others all have full access.

Extremely broad and rarely appropriate for sensitive or production content.
r--r--r--

Everyone can read; nobody can write or execute.

May fit truly public reference material, but sensitivity and exposure still require review.

Core Concept

Effective Access Comes From Identity, Groups, Ownership, Permissions, and Context

A permission string cannot be interpreted correctly without knowing the object owner, group owner, account memberships, file type, path, service relationship, and approved purpose. Direct ownership, group-based access, directory traversal, and service behavior all contribute to what an account can actually do.

Intermediate habit: ask “Which identity receives this permission, through which ownership or group relationship, for which approved task, and for how long?”

Key Vocabulary

Linux Identity and Permission Terms

User account

A named identity used by a person, service, application, or system process.

Group

A collection of accounts used to organize shared access and responsibilities.

Primary group

The default group associated with a user account.

Supplementary group

An additional group that grants access beyond the primary group.

Owner

The user account recorded as owning a file or directory.

Group owner

The group associated with a file or directory for group-based access.

Read permission

Permission to read file contents or list directory entries, depending on object type.

Write permission

Permission to modify a file or create, remove, or rename entries within a directory, depending on context.

Execute permission

Permission to run a file or traverse and access a directory path, depending on object type.

Least privilege

Giving only the minimum access needed for an approved role and duration.

Service account

A nonhuman account used by an application, background service, automation, or scheduled task.

Privileged account

An account with elevated authority that requires strong controls, limited use, and detailed monitoring.

Evidence Analysis

What Account and Permission Evidence Can and Cannot Prove

Evidence source

Account inventory

Can support

Account name, type, owner, status, shell, home directory, creation date, and lifecycle.

Limitation

Does not prove current activity, legitimate purpose, or all effective permissions.

Evidence source

Group membership

Can support

Primary and supplementary groups associated with an account.

Limitation

Does not prove why membership exists, whether it is still needed, or which files it affects.

Evidence source

File and directory metadata

Can support

Owner, group owner, symbolic permissions, timestamps, object type, and path.

Limitation

Does not prove the complete business purpose or every indirect access path.

Evidence source

Service configuration

Can support

Which account a service uses and which paths or resources it requires.

Limitation

Does not prove every permission is necessary or correctly scoped.

Evidence source

Authentication and activity logs

Can support

Login events, account use, failures, privilege events, and timestamps.

Limitation

Absence of events may reflect missing logs, inactive use, or limited retention.

Evidence source

Role and change records

Can support

Approved job role, project need, owner, temporary access, review date, and removal plan.

Limitation

Does not prove the final technical state matches the approval.

Defensive Workflow

Review Users, Groups, and Permissions in Six Steps

1

Identify the identity

Record the fictional account name, type, owner, role, status, shell, home directory, and lifecycle.

2

Map group membership

Review primary and supplementary groups and connect each one to an approved responsibility.

3

Read ownership and permissions

Interpret owner, group owner, read, write, execute, directory traversal, and effective access context.

4

Compare with business need

Check job role, service dependency, data sensitivity, project duration, and approved baseline.

5

Find excess or stale access

Identify broad permissions, old groups, shared accounts, temporary access, unknown owners, or disabled users retaining access.

6

Recommend controlled correction

Document owner, impact, authorization, exact change, testing, validation, rollback, and review date.

Fake Dashboard

Fake Linux Access Review Dashboard

Training dashboard for the fictional Northstar Learning Services environment.

Active accounts

27

Standard users, administrators, service accounts, and one approved temporary account are listed.

Expired temporary access

2

Two project accounts remain enabled beyond their approved end dates.

Broad permission findings

3

One shared directory grants write access to all local users and two files have incorrect group ownership.

Fake SOC Alert

Expired Project Account Retains Write Access to Production Content

Source: Fake Linux Access Governance Monitor • Time: 02:36 PM

High Severity
The fictional account temp-content-support expired seven days ago but remains enabled and still belongs to the web-content group. That group has write access to /srv/training-web/public. No current ticket, owner request, or approved extension is documented.
Defensive recommendation: Preserve account, group, permission, ownership, activity, and project evidence; confirm that no active dependency remains; then request authorized account disablement and group removal with validation and rollback.

Fake Log Panel

Fake Account and Permission Evidence Timeline

training-log-viewer.log
14:03:00 ACCOUNT user='temp-content-support' type='temporary' status='enabled'
14:03:00 ACCOUNT_META owner='content-project' expiration='7_days_ago'
14:05:22 GROUP user='temp-content-support' membership='web-content'
14:07:14 PATH path='/srv/training-web/public' owner='deploy-user' group='web-content' permissions='rwxrwxr-x'
14:11:39 ACTIVITY user='temp-content-support' last_login='12_days_ago' recent_file_changes='0'
14:18:04 PROJECT status='complete' active_support_need='none'
14:21:47 CHANGE approved_extension='none'
14:27:15 OWNER_CONFIRMATION account_required='false'
14:36:08 CORRELATION finding='expired_account_retains_production_write_access' confidence='high'

Training note: this is fake data for defensive analysis practice only.

Analyze the Evidence

Which Access-Control Conclusion Is Best Supported?

The fictional account temp-content-support is classified as temporary.
Its approved expiration was seven days ago.
The account remains enabled and belongs to the web-content group.
The web-content group has write access to the production public-content directory.
The project is complete and the owner confirms no active support need.
No approved extension or current dependency is documented.

What is the strongest conclusion and next action?

Common Mistakes

Mistakes That Weaken Identity and Permission Review

Assuming account existence proves current business need.
Removing a user from a group without checking service, project, and file dependencies.
Treating rwxrwxrwx as convenient instead of recognizing extremely broad access.
Ignoring directory execute permission and focusing only on read and write.
Giving users permanent administrator access for occasional support tasks.
Using shared accounts without ownership, logging, expiration, or accountability.
Leaving temporary vendor or project accounts active after the approved end date.
Changing ownership before preserving the original metadata and audit context.
Assuming a disabled account cannot still own sensitive files or scheduled tasks.
Publishing real usernames, groups, permissions, or internal paths in a portfolio.

Safe Practice Lab

Complete a Fictional Linux Access Review

Fictional Environment

Meadowbrook Learning Portal Access Matrix

Review fictional users, administrators, service accounts, temporary support accounts, groups, files, directories, permissions, owners, activity records, and project changes.

Required Analysis

  1. Classify each account by type, owner, role, status, and lifecycle.
  2. Map primary and supplementary groups to approved responsibilities.
  3. Interpret owner, group owner, and symbolic permissions.
  4. Identify broad, stale, temporary, shared, unknown, or unnecessary access.
  5. Check service dependencies and directory traversal requirements.
  6. Separate confirmed facts, likely explanations, and missing evidence.
  7. Write an authorized least-privilege correction and validation plan.
Use only supplied fictional records. Do not create, modify, disable, elevate, or remove accounts, groups, ownership, or permissions on any real Linux device, server, website, cloud system, or school computer.

Scenario Decision Lab

A Service Account Can Write to Every User Home Directory

A fictional backup service account needs read access to selected approved data paths but has group membership that also grants write access across all user home directories.

Scenario Decision Lab

A Disabled User Still Owns an Important Application Directory

A fictional former developer account is disabled but remains the owner of /opt/training-app. The active service runs under a separate service account and the ownership baseline expects the application team group.

Defender Habits

Linux Users, Groups, and Permissions Review Checklist

Check Your Understanding

I2.3 Mini Quiz: Users, Groups, and Permissions

Choose your answers first. Explanations appear only after submission.

1. What is the purpose of a Linux group?

2. What does rw-r----- mean?

3. Why is execute permission important on a directory?

4. Which account should normally have the narrowest permissions needed for one application?

5. What is the strongest evidence that group membership is still required?

6. A temporary support account remains enabled after its approved expiration. What is the strongest next step?

7. Why should defenders review ownership as well as permissions?

Portfolio Prompt

Portfolio Prompt

Create a fictional Linux Access Governance Matrix for a learning-portal environment. Include standard users, administrators, service accounts, temporary support accounts, shared legacy accounts, groups, important files and directories, ownership, symbolic permissions, approved purpose, expiration, activity evidence, risk, and recommended action.

Use only fictional users, groups, paths, services, systems, logs, and organizations.
Include one expired temporary account, one overprivileged service account, one disabled owner, and one broadly writable directory.
Explain the effective access path for each major finding.
Do not include real usernames, groups, permissions, home directories, credentials, or production details.

Key Takeaways

What You Should Remember

1.Linux access depends on users, groups, ownership, symbolic permissions, object type, path, and context.
2.Read, write, and execute permissions behave differently for files and directories.
3.Service and privileged accounts require narrow scope, named ownership, logging, and periodic review.
4.Temporary, shared, disabled, and stale accounts can retain meaningful access.
5.Least privilege balances security with approved operational dependencies.
6.Safe corrections preserve evidence and use authorization, testing, validation, rollback, and documentation.

Navigation

Continue Module I2

Previous: I2.2 Files, Directories, and PathsBack to ModuleNext: I2.4 Processes and Services