Build a service-access investigation runbook

Work from a fixed case

Use this fictional case as your final project. A service named agent-reader should read /srv/agent/config/agent.conf. Its startup record at 09:10 UTC says “configuration read failed.” The service runs as user agent, group agent, supplemental group telemetry. It does not run as root. The supplied path evidence is:

/srv                     root:root       755
/srv/agent               root:root       700
/srv/agent/config        root:telemetry  750
/srv/agent/config/agent.conf root:telemetry 640
Interactive administrator: root
Administrator cat result: success
Service working directory: /var/lib/agent
Configured path: /srv/agent/config/agent.conf

First separate facts from hypotheses. The configuration path is absolute, so the service's different working directory is not itself the cause. The administrator's successful read occurs under a different privilege context. The ordinary service identity cannot traverse /srv/agent under the supplied basic mode bits. This is a supported explanation of the access failure, assuming no additional ACL, security module, namespace or mount rule changes the effective decision.

Do not change the case to fit your favorite tool. A diagnosis should remain tied to the supplied identity and path components.

Write the investigation sequence

Your runbook should establish the service identity, configured path, event time and actual error first. Next inspect each path component's owner, group, mode and relevant additional controls. Compare the configured path with the file the administrator tested. Check for symlinks, mounts or service isolation when the visible paths differ.

Record observations before proposing a repair. A worksheet with columns for command/context, observation, supported inference and next question is suitable. “The administrator can read it” belongs in observation; “therefore the service can read it” is an unsupported inference.

Include a branch for a missing path and a branch for a denied path. If a service points to a nonexistent file, widening permissions on a different file will not repair the configured path. If the file is accessible but contains an unsupported format, a permission change will not repair parsing. These branches make the runbook useful beyond a single copied example.

Design the narrow repair

Propose a policy in which the intended service identity can traverse the necessary directories and read the configuration, while unrelated identities remain excluded. The exact implementation depends on the owner-approved sharing model: a service group, a suitable ACL, or another controlled delivery design may be appropriate. Do not run an invented ownership command against a real /srv path.

For the supplied case, making /srv/agent traversable by the intended telemetry group could address the identified basic-mode barrier if the owner adopts that group design. Document the previous owner/group/mode, the proposed values, who authorizes the change and how they will be restored if verification fails. A broad recursive change can alter unrelated files and exceeds the single read objective.

The runbook must include negative checks. Confirm that an unrelated unprivileged identity still cannot read the file. Confirm that the service cannot write the file if it only needs to read it. Confirm that the path tested is the path actually configured. A successful read is one part of acceptance, not the whole policy.

Verify the service outcome separately

After an approved repair in a real environment, repeat the read under the actual service identity or use the service's supported diagnostic path. Then verify the service's own load result. A readable file with invalid syntax can still cause startup failure. If a restart is needed, document its operational impact and owner-approved timing; a teaching example does not authorize it.

Record before/after event evidence and a rollback trigger. A repaired file-access test that leaves the service failing should reopen the investigation rather than be declared a success. A report should retain uncertainty about controls you did not inspect.

Independent challenge cases

Case A changes only the configured path to config/agent.conf, while keeping the working directory /var/lib/agent. Explain why the service now resolves a different path. Case B makes the parent directories accessible to the service but gives the file mode 600 owned by root. Explain why the original directory repair is insufficient. Case C keeps all ordinary access valid but the service log reports an invalid configuration key. Explain why additional permissions are not a supported repair.

For each case, state one discriminating observation that would help select the correct branch. Avoid collecting every possible command merely to make the runbook look long. Useful diagnostics reduce uncertainty in a defined decision.

Deliverable and self-review

Submit the lab observations, the fixed-case evidence map and your runbook with three challenge branches. Include an identity-aware acceptance matrix: service read allowed, service write denied, unrelated-user read denied, correct path confirmed, format accepted and service load confirmed. Mark any check that is a design proposal rather than an executed test.

Explain why root's successful read is weak evidence for ordinary service access; why directory execute permission differs from executable-file permission; why an empty pipeline output needs an exit-status check; and why the previous file mode must be captured before a practice change.

The course is complete when you can choose a command for a specific evidence question, predict its limits, and propose a narrow verified repair. The website's completion record tracks your study; it does not grant Linux administration authority or certify a production change.

References: https://www.gnu.org/software/coreutils/manual/html_node/File-permissions.html and https://www.gnu.org/software/bash/manual/html_node/Pipelines.html

Transfer project — changed conditions

Create the case only in an authorized disposable lab, or manually trace permission bits if you cannot create users. Add a readable file inside a nontraversable parent and explain the result. Add a service that writes output and distinguish read from write requirements. Submit the effective identity, each path component, expected permission decision and a proposed least-privilege correction with a negative test for an unrelated user.

Practical assessment rubric

Score each dimension 0–2: 0 = absent or materially incorrect; 1 = partly correct with an unresolved gap; 2 = correct, explicit and supported by the supplied evidence or an actual labeled lab result.

1. Evidence/model: identify the relevant entities, inputs, assumptions and boundaries without inventing facts.
2. Main result: derive the case-specific expected result, calculation or decision and show the intermediate reasoning.
3. Failure/boundary: test the changed condition and explain why the original conclusion does or does not transfer.
4. Verification: supply reproducible steps and expected/observed results; label manual traces as manual, not executed.
5. Communication/safety: explain limitations, owners and a proportionate next action without unsafe or unnecessary access.

Target: at least 8/10, with no zero in main result or communication/safety. This is a local learning rubric, not an accredited certification standard. A written/manual solution demonstrates reasoning only; operational competence additionally requires the relevant executable lab in an authorized environment. The native multiple-choice score is separate and does not automatically grade this rubric.

Submission template

• My input/evidence and assumptions:
• Expected result with calculations or trace:
• My implementation/decision and justification:
• Changed-condition result:
• Observed execution, or explicitly labeled manual trace:
• Failure and recovery evidence:
• Unverified limitation and next action:
• Self-score with evidence for each dimension:

Remediation

If the main result is wrong, reconstruct the supplied case from the raw inputs before changing code or controls. If the boundary case is wrong, identify the assumption that changed and rerun both the original and changed case. If verification is missing, do not convert a prediction into an observed result. Reattempt the transfer task without copying the worked solution, then explain it to another person.

Official reference for further study

Assessment: explain your decisions

Choose an answer and write your reason before opening each explanation. Then explain why the other choices do not fit the evidence. Use missed questions to revisit the lesson. This knowledge check is only one part of assessment: complete the practical transfer project as well. It does not predict certification-exam success.

1. What does pwd show?

1. Current working directory
2. All passwords
3. A privilege grant

Answer and explanation

Current working directory — pwd establishes path context.

2. Why quote a path with spaces?

1. To change its permissions
2. To pass it as one argument
3. To encrypt it

Answer and explanation

To pass it as one argument — The shell otherwise separates words.

3. What is better than chmod 777 as a blanket fix?

1. Disable all logging
2. Always use root
3. Inspect identity and grant required minimum access

Answer and explanation

Inspect identity and grant required minimum access — Access should match the intended task and identity.

4. Root can read a config, but the normal service user fails. What does the successful root read establish?

1. That privileged process could read it in its context; service access still needs verification.
2. The service must be using an incorrect password.
3. Every service on the machine can read the config.

Answer and explanation

That privileged process could read it in its context; service access still needs verification. — Effective identities and privileges differ. Inspect every path component under the service context, plus relevant ACL or isolation controls. A privileged read is weak evidence for ordinary service access.

5. The file is group-readable, but its parent directory is inaccessible to the service group. Which basic permission is relevant to reaching the file?

1. World-write access on all parent directories.
2. Directory search/execute access along the path.
3. Execute permission on the configuration file.

Answer and explanation

Directory search/execute access along the path. — Directory search permission is needed to traverse the path. Making a data file executable does not solve a parent traversal barrier; broad write access exceeds the read objective.

6. In Bash, false | cat returns status 0 under the default pipeline rule. Why?

1. The false command was silently corrected.
2. The pipeline proves both commands succeeded.
3. The default pipeline status comes from the final command; an upstream failure can be hidden.

Answer and explanation

The default pipeline status comes from the final command; an upstream failure can be hidden. — cat can successfully consume an empty stream after false fails. A deliberate pipefail boundary can surface the upstream failure, but each command status still needs interpretation under its own contract.

7. Can bob read the file under the supplied simplified model?

1. Yes, through team group traversal and read permissions.
2. No, because bob is not the owner.
3. Yes only if every path is777.

Answer and explanation

Yes, through team group traversal and read permissions. — Group permissions can authorize access. Ownership is not the only applicable permission class.

8. Why does root’s successful read not verify the service?

1. Root changes the file name automatically.
2. The service has a different effective identity and permissions.
3. All users have identical access.

Answer and explanation

The service has a different effective identity and permissions. — Testing as an administrator can bypass the boundary that fails for the service account.

9. What is wrong with a blanket recursive777 fix?

1. It is the only way to permit group read.
2. It guarantees service correctness forever.
3. It grants broad access beyond the stated requirement and masks the intended boundary.

Answer and explanation

It grants broad access beyond the stated requirement and masks the intended boundary. — Least-privilege diagnosis should target the required identity/path. Broad permissions add exposure without proving the application works.

Open the scored course assessment to use the existing practice-test engine. Earlier attempts remain part of your history.