Understand permissions before proposing a repair

Ordinary mode bits describe three identity classes

For a regular file, the basic read, write and execute bits apply to owner, group and other identities. A long listing such as -rw-r----- describes a regular file whose owner can read and write, whose group can read, and whose other identities have no basic permissions. The displayed owner and group determine which class may apply to the process.

Inspect the lab file:

ls -l "$lab_dir/config/agent.conf"
stat -c 'mode=%a owner=%U group=%G path=%n' "$lab_dir/config/agent.conf"
id

stat prints the chosen format explicitly. Record the actual mode rather than assuming a tutorial's default. File creation permissions can be influenced by the process's creation mode and umask. A file that was readable in one lab may not have the same mode in another environment.

The basic identity classes are not an additive checklist in which a process always combines every visible bit. The ordinary owner/group/other selection rules matter. Extended ACLs and privileged capabilities can affect effective access too. Inspect those mechanisms when present; a nine-character permission display may not describe the entire policy.

Directory execute permission means traversal

For a directory, read permission lets a process list names; execute/search permission lets it traverse the directory and resolve entries. Write permission relates to modifying directory entries, often in combination with search permission. These meanings differ from executing a regular program file.

A readable configuration file behind an unsearchable parent directory can still be inaccessible. To reason about /srv/agent/config/agent.conf, inspect access to /, /srv, /srv/agent, /srv/agent/config and the file itself. If namei is installed, namei -l can help show path components. If it is unavailable, inspect each known parent with ls -ld and state the limitation.

Do not fix a path traversal issue by making every file executable. Execute permission on a data file is unrelated to the directory search permission the process needs.

Practise a reversible owner-mode change

The following exercise changes only the lab file you created:

before_mode=$(stat -c '%a' "$lab_dir/config/agent.conf")
printf 'Original mode: %s\n' "$before_mode"
chmod u-r "$lab_dir/config/agent.conf"
ls -l "$lab_dir/config/agent.conf"
cat "$lab_dir/config/agent.conf"
printf 'Read exit status: %s\n' "$?"
chmod "$before_mode" "$lab_dir/config/agent.conf"
cat "$lab_dir/config/agent.conf"

A normal, unprivileged owner should be unable to read the file after removing the owner-read bit, then should be able to read it again after restoration. If you are running as root or with an effective privilege that bypasses the relevant check, the expected failure may not occur. Record that difference and repeat in a suitable unprivileged environment. Do not call a privileged successful read proof that the ordinary service identity has access.

The restoration uses the mode captured before the change. A repair that guesses a mode without recording the starting point loses useful evidence and may overwrite an intentional policy. In a real environment, ownership, ACLs and other controls also need consideration.

Umask is a creation constraint

umask influences the permissions allowed when a process creates files or directories. It does not retroactively change every existing file. Inspect it with umask, and record the value in a reproducibility note if newly created modes matter to your test.

If you practise a different umask, do it in a subshell so that the parent shell's setting survives:

(
    umask 077
    printf 'private practice\n' > "$lab_dir/config/private-note.txt"
    stat -c '%a %n' "$lab_dir/config/private-note.txt"
)
umask

For a normal newly created regular file with the usual non-executable creation request, the private note should have mode 600. The final umask runs in the parent shell and should show its original setting. State your observed result, including any environment-specific difference.

A restrictive creation policy can be useful, but it can also reveal a missing handoff contract: a collector creates a file privately while a separate reader expects group access. The solution needs an agreed owner/group and sharing boundary, not a universal recommendation to make files public.

Case reasoning

A service has effective user agent, supplemental group telemetry, and no elevated privileges. The configuration file is owned by root:telemetry with mode 640. Its parent directory is owned by root:root with mode 700. Under ordinary mode-bit reasoning, identify why the group-readable file remains inaccessible. The group has read permission on the file, but the service cannot traverse the parent directory.

A proposed repair of chmod 777 on the directory would grant write access broadly and exceeds the read-only objective. Propose a narrowly scoped directory access design for the intended service group, verify that unrelated identities remain excluded, and have the system owner approve the actual change. This is a reasoning exercise, not a command to run against /srv on your own machine.

Evidence laboratory — attempt before reading the solution

Fictional lab paths: /srv/team owned root:team with mode750; /srv/team/report.txt owned alice:team with mode640. User bob belongs to team. Service user agent belongs only to agents. No ACLs, special security modules or other exceptions are in this simplified case. Predict whether bob and agent can traverse the directory and read the file. An administrator reads it successfully as root and concludes the service should work; explain the missing comparison.

Official reference for further study