Skip to content
learnwithsk.dev
← Systems Foundations

Practical lab guide

Lab: recover access to a configuration file

Create a temporary tree, reproduce a directory-access failure, and make a scoped repair.

  • Linux
Documentation reviewed2026-10-26 · 3 min read · lab time varies
  1. Why
  2. Predict
  3. Try
  4. Inspect
  5. Explain
  6. Save evidence

Predict before you try

If a file is readable but its parent directory cannot be traversed, will the intended user be able to open it?

Try it: Build the baseline →
On this page

Environment and status

Run interactively in Bash inside a disposable Linux VM as a regular user. Coreutils must be available. Run the steps in the same terminal so the lab variable remains defined. This guide has been reviewed against documentation; it has not yet been run in the target Linux VM and is not labeled lab-verified.

The exercise touches only a new temporary directory. It needs no cloud services, application deployment, or elevated privileges. Check id -u; if it returns 0, switch to a regular account before beginning.

Build the baseline

bash
id -u
study_lab_dir=$(mktemp -d /tmp/learnwithsk-access.XXXXXX)

Continue only if directory creation succeeds. The variable should contain the new path. Inspect it, then create the fixture:

bash
printf '%s\n' "$study_lab_dir"
mkdir "$study_lab_dir/config"
printf 'environment=local\n' > "$study_lab_dir/config/settings.txt"
chmod 700 "$study_lab_dir/config"
chmod 600 "$study_lab_dir/config/settings.txt"
cat "$study_lab_dir/config/settings.txt"

The final command should display the line you wrote. If it fails, investigate before introducing the fault.

Before introducing the fault, annotate the expected ordinary modes: 700 on config is owner rwx with no group/other access; 600 on settings.txt is owner rw- with no group/other access. Predict which bit the next command removes and which path lookup will need it. This connects the octal reading exercise to the failure instead of relying on the error message alone.

Break one assumption

bash
chmod u-x "$study_lab_dir/config"
ls -ld "$study_lab_dir/config"
cat "$study_lab_dir/config/settings.txt"

For this regular-user setup, the read should fail because the directory can no longer be searched by its owner. Record the actual error; wording may vary. Do not use sudo to bypass the observation.

Diagnose and recover

Which object changed: the file or its parent directory? Restore only the removed owner permission:

bash
chmod u+x "$study_lab_dir/config"
cat "$study_lab_dir/config/settings.txt"
ls -ld "$study_lab_dir/config"
ls -l "$study_lab_dir/config/settings.txt"

Verify the original read succeeds and that group/other access was not opened. Capture your before/after observations in the notes field.

If you did not observe the expected failure, check whether you used root, a different filesystem, or a different path. Stop and document the difference rather than claiming the lab passed.

Complete a four-row comparison in your notes: baseline read, failed read, repaired read, and final file/directory modes. Explain why the repair changes directory traversal without making the configuration file executable or public. If you used a different identity for any row, repeat the comparison with the intended regular user before drawing a conclusion.

Clean up

After confirming the variable still points to the temporary directory created above, remove only these known fixture entries. No recursive deletion is needed.

bash
rm -- "$study_lab_dir/config/settings.txt"
rmdir -- "$study_lab_dir/config"
rmdir -- "$study_lab_dir"
unset study_lab_dir

If cleanup fails, inspect the specific error and restore the lab directory's owner search permission if necessary. Do not expand the deletion scope.

Apply this to MicroBank

Label the output as a MicroBank configuration-access learning fixture. Its deliberately blocked parent directory teaches a failure you may later meet in an application runtime, while keeping real configuration untouched. Explain the smallest repair and repeat the original read. Put the report in the readiness project; the fixture does not establish any application service account permissions.

Keep this observation in the MicroBank readiness project.

Sources

References: GNU mktemp↗ and symbolic permission changes↗. The fixture and observations here are instructional, not production evidence.

Prove what you learned

Inspect the result

Compare intended-user access before and after the smallest scoped repair; retain the resulting modes.

Explain it in your own words

Explain why your observation supports the stated outcome, and name one thing it does not prove.

Try a small variation

Change one parent-directory permission in the disposable fixture instead of changing the file mode.

Your evidence should show

  • Record the context/revision or label the work as a paper or prepared fixture.
  • Compare the prediction with the actual result from “Build the baseline”.
  • Compare intended-user access before and after the smallest scoped repair; retain the resulting modes.
  • Explain the transfer challenge and retain the same verification question.
Hint

Inspect the effective user and each parent directory, not only the file.

Answer guide: compare after predicting

No. Directory search permission and the file permission are separate checks. Verify as the intended identity.

Compare this with your actual observation. A paper answer is useful reasoning practice; record execution separately.

Recall how a path is resolved from the current directory. Revisit the previous lesson.

Save the prediction, result and explanation ↓

Your notes and evidence

Record observations, questions, or links to your work. Keep credentials out of your notes.

Loading saved progress…

Back up or restore this path

Progress and notes stay in this browser. A backup contains only this learning path.