Skip to content
← System engineer 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.

Documentation reviewed2026-10-01 · 3 min read · lab time varies
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.

Sources

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

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.