I2.2 Files, Directories, and Paths
Read fictional Linux filesystem paths, directories, metadata, ownership, service locations, temporary files, and evidence safely without changing system state.
Lesson Progress
Files, Directories, and Paths
High School Intermediate • I2: Linux Basics for Security • Lesson 2 of 8
Readiness Check
Before You Start
0/5 ready
Professional Hook
The Same File Can Be Normal in One Location and Dangerous in Another
A configuration file in an approved service directory may be expected. The same file copied into a publicly served directory may expose internal settings. A temporary installer file may be normal during an update but suspicious months later. Defenders review the full path, owner, permissions, service relationship, timestamps, sensitivity, and change history.
Weak response
“The filename looks unusual, so delete it.”
Strong response
“Preserve the exact path and metadata, identify the using user or service, compare the baseline and change history, and act only through authorized correction.”
Objective 1
Explain absolute paths, relative paths, the root directory, home directories, hidden files, and common Linux filesystem locations.
Objective 2
Connect file and directory locations with system purpose, ownership, sensitivity, evidence value, and defensive risk.
Objective 3
Interpret fictional directory listings and metadata without changing system state.
Objective 4
Distinguish expected system files from temporary, user-created, stale, misplaced, or review-required content.
Objective 5
Create a safe fictional filesystem map that separates confirmed facts, likely explanations, and missing evidence.
Why This Matters
Filesystem Structure Helps Defenders Understand Purpose, Exposure, and Evidence
Linux paths reveal where configuration, logs, user data, applications, temporary files, backups, and service content are stored. That location helps defenders connect a file with its owner, process, application, sensitivity, access path, and expected lifecycle.
Filesystem Map
Common Linux Directories and Defensive Questions
/etc
System-wide configuration files and service settings.
Defender questions
Which application owns the file? Was the change approved? Do permissions and timestamps match expectations?
/var/log
System, authentication, service, application, and monitoring logs.
Defender questions
Are timestamps aligned? Is collection complete? Which owner and retention policy apply?
/home
User home directories, personal settings, documents, and approved work.
Defender questions
Does the account still exist? Are sensitive files stored appropriately? Are hidden files expected?
/root
The home directory for the root administrative account.
Defender questions
Is access tightly restricted? Are scripts and keys approved, owned, and documented?
/srv
Data served by approved applications or network services.
Defender questions
Which service uses the content? Who owns it? Are permissions and backups appropriate?
/tmp
Temporary storage used by users, applications, installers, and services.
Defender questions
Is the file expected, current, owned correctly, and safe to retain? Does it contain sensitive data?
/usr
User-space applications, libraries, commands, documentation, and shared data.
Defender questions
Was software installed through approved packages? Does the location match the baseline?
/var
Variable data such as logs, caches, queues, databases, websites, and application state.
Defender questions
Which service owns the data? Is growth expected? Are retention, permissions, and backups correct?
/opt
Optional or third-party application software.
Defender questions
Is the software approved, supported, owned, updated, and required by the current system role?
/mnt and /media
Common locations for mounted storage, removable media, or temporary filesystem access.
Defender questions
Who mounted the resource? Is it approved? What data, permissions, and lifecycle apply?
Path Interpretation
Location Changes the Defensive Meaning
Expected system path
The location fits a configuration role, but ownership, permissions, change history, and content purpose still require review.
Expected service data
The path fits the fictional web-server role when the service owner, backup, access, and deployment records agree.
User-created content
The location may be normal for approved user work, but sensitivity, sharing, ownership, and retention matter.
Temporary content
The path may be normal during an approved update but should be correlated with process, owner, time, and cleanup evidence.
Misplaced sensitive file
A publicly served directory is an inappropriate location for internal documentation and requires controlled correction.
Stale or unknown content
The location alone does not prove risk, but unknown ownership, expired purpose, or unsupported software requires review.
Core Concept
Always Review the Full Path and Context
The name report.txt says very little by itself. The path /home/student-analyst/report.txt suggests approved user work, while /srv/training-web/public/report.txt suggests the file may be served to application users. Defenders also review symbolic-link targets, mounts, ownership, permissions, timestamps, service use, and change records.
Key Vocabulary
Linux Filesystem and Path Terms
Root directory
The top of the Linux filesystem hierarchy, represented by a single forward slash.
Absolute path
A complete path that begins at the root directory, such as /var/log/training-app.log.
Relative path
A path interpreted from the current working directory rather than from the root.
Home directory
A user-specific location for personal files, settings, and approved work.
Current working directory
The directory where the shell or application is currently operating.
Parent directory
The directory one level above the current directory, commonly represented by two dots.
Hidden file
A file or directory whose name begins with a dot and is normally omitted from basic listings.
Mount point
A directory where another filesystem, device, or storage resource becomes accessible.
Symbolic link
A filesystem reference that points to another file or directory.
Configuration file
A file containing settings that control system, service, or application behavior.
Temporary file
A short-lived file created during normal processing, updates, sessions, or application work.
Filesystem metadata
Information such as ownership, permissions, timestamps, type, size, and location.
Evidence Analysis
What Filesystem Evidence Can and Cannot Prove
Evidence source
Directory listing
Can support
Names, file types, sizes, ownership, permissions, and sometimes timestamps.
Limitation
Does not prove file contents, business purpose, current use, or safety by itself.
Evidence source
File metadata
Can support
Owner, group, permissions, timestamps, size, type, and link information.
Limitation
Timestamps may change for multiple reasons and do not prove who performed an action.
Evidence source
Asset and role baseline
Can support
Which directories, applications, logs, and data locations should exist for the system role.
Limitation
May be incomplete or stale unless validated against current evidence.
Evidence source
Service configuration
Can support
Which paths an application reads, writes, serves, logs to, or uses for data.
Limitation
Does not prove the current service process is active or every file is required.
Evidence source
Process and open-file evidence
Can support
Which process is currently using a file or directory.
Limitation
Does not prove long-term ownership, approved purpose, or future use.
Evidence source
Change and deployment records
Can support
Approved creation, modification, movement, removal, backup, and rollback activity.
Limitation
Does not prove no undocumented change occurred.
Defensive Workflow
Review a File or Directory in Six Steps
Identify the path
Record the exact fictional absolute path, type, owner, group, permissions, size, and timestamps.
Connect it to system role
Ask whether the location fits the approved web, database, file, monitoring, workstation, or gateway role.
Find the using service or user
Correlate the path with a process, service, account, application, package, deployment, or backup record.
Assess sensitivity and exposure
Determine whether the location is private, shared, temporary, served publicly, backed up, or accessible across zones.
Compare with baseline and changes
Check expected paths, ownership, permissions, approved changes, timestamps, and lifecycle.
Recommend a controlled action
Document the owner, risk, evidence, authorization, safe move or correction, validation, and rollback.
Fake Dashboard
Fake Linux Filesystem Review Dashboard
Training dashboard for the fictional Harborview Learning Portal.
Reviewed paths
34
Configuration, logs, service data, user files, temporary content, and optional software were compared.
Misplaced sensitive files
1
An internal deployment note appears inside a publicly served directory.
Unknown legacy directories
2
Two /opt locations have no confirmed owner, active package, or current dependency.
Fake SOC Alert
Internal Deployment Notes Stored in Public Web Content
Source: Fake Linux Filesystem Monitor • Time: 01:24 PM
Fake Log Panel
Fake Filesystem Evidence Timeline
12:58:00 BASELINE public_path='/srv/training-web/public' classification='public-content-only' 13:02:11 FILE path='/srv/training-web/public/internal-deployment-notes.txt' owner='deploy-user' group='web-content' 13:02:11 METADATA permissions='0644' modified='today_12:41' size='18KB' 13:04:29 CLASSIFICATION file='internal-deployment-notes.txt' sensitivity='internal' 13:06:42 WEB_SERVICE document_root='/srv/training-web/public' state='running' 13:09:18 ACCESS_TEST fictional_url='/internal-deployment-notes.txt' result='served' 13:14:06 DEPLOYMENT expected_internal_docs_path='/srv/training-web/private-docs' 13:18:53 OWNER_CONFIRMATION public_location='not_approved' move_required='true' 13:24:17 CORRELATION finding='misplaced_internal_file_in_public_path' confidence='high'
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Which Filesystem Conclusion Is Best Supported?
What is the strongest conclusion and next action?
Common Mistakes
Mistakes That Weaken Filesystem Analysis
Safe Practice Lab
Map a Fictional Linux Filesystem
Fictional Environment
Meadowbrook Training Web Server
Review a supplied fictional directory tree containing configuration, service data, logs, user files, packages, temporary files, mounted backups, symbolic links, and legacy application directories.
Required Analysis
- Label every path as system, service, user, temporary, mounted, linked, or legacy.
- Record owner, group, permissions, size, and timestamps.
- Connect important paths to services, users, packages, and backups.
- Identify misplaced, stale, unknown, sensitive, or exposed content.
- State what each item confirms and what remains uncertain.
- Prioritize findings by sensitivity, exposure, dependency, and owner.
- Write an authorized correction, validation, and rollback plan.
Scenario Decision Lab
A Large File Appears in /tmp During an Approved Update
A fictional server creates /tmp/training-update-4821 while an approved package update is running. The file is owned by the package service, its timestamp matches the change window, and the update remains active.
Scenario Decision Lab
A Symbolic Link Points Outside the Approved Service Directory
A fictional web-content link under /srv/training-web/public points to /home/deploy-user/private-notes. The target contains internal deployment documentation.
Defender Habits
Linux Filesystem Review Checklist
Check Your Understanding
I2.2 Mini Quiz: Files, Directories, and Paths
Choose your answers first. Explanations appear only after submission.
1. Which path is absolute?
2. What does a filename beginning with a dot commonly indicate?
3. Which directory commonly stores system-wide configuration?
4. Why is /var/log important to defenders?
5. What does file metadata prove?
6. A confidential internal note appears in a fictional web server's public content directory. What is the strongest response?
7. Why should defenders review a symbolic link's destination?
Portfolio Prompt
Portfolio Prompt
Create a fictional Linux Filesystem Security Map for a learning-portal server. Include /etc, /var/log, /home, /root, /srv, /tmp, /usr, /var, /opt, and one mounted backup location. For each path, show purpose, owner, sensitivity, expected contents, service relationship, permissions concept, logging or backup need, and review questions.
Key Takeaways
What You Should Remember
Navigation