Build a permission diagnosis

Turn an error into a specific access question

“Permission denied” does not identify the failing check. A program may be unable to search a parent directory, read a file, write an existing file, or create a new directory entry. Start with four facts: the account, the path, the working directory, and the requested operation.

Use the Ubuntu learning machine as a regular user. This worked failure is deliberately limited to a new temporary directory; keep this terminal open through cleanup.

study_access=$(mktemp -d)
mkdir "$study_access/config"
printf 'theme=plain\n' > "$study_access/config/settings.txt"
chmod 600 "$study_access/config/settings.txt"
chmod 600 "$study_access/config"
id
ls -ld "$study_access" "$study_access/config"
cat "$study_access/config/settings.txt"

The final read should fail under ordinary user permissions. The file has owner read access, but config is a directory with owner rw-: it lacks search permission. File lookup cannot reach settings.txt. A failed ls -l on the child is therefore useful evidence, not proof that the child is absent.

If available, namei -l "$study_access/config/settings.txt" displays each path component and its mode. It helps spot an inaccessible parent several levels above the file. This read-only tool may itself stop where your account cannot inspect further.

Predict a repair before making it

The owner needs to resolve a name within config. The smallest missing bit is owner search, so add that bit to that directory:

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

Expected content is theme=plain; expected directory owner mode is now rwx. The file remains private (600). Reading it with sudo would change the requesting identity and would not demonstrate that the original user can read it. Likewise, making every file world-writable would not test the hypothesis carefully.

When the ordinary bits do not explain it

Check the actual process identity, not just your login. Services may use another account, an older set of supplementary groups, or a different filesystem view. Resolve symbolic links and verify the final target. Then inspect the relevant extra layer:

An ACL is an access control list that can grant named users or groups additional rules; its mask can limit several entries. A default directory ACL affects newly created children. Do not start changing ACLs or security policy until there is evidence that they caused this failure. Those deeper administration exercises are optional here.

Explain the result without guessing

A useful note would say: “My regular user could not read this fixture because its config parent had no owner search bit. I added u+x to that directory and repeated the same read successfully.” Write that only if it matches your actual observations. If the read unexpectedly succeeds, check whether you used root or a different filesystem.

Why inspect the resulting file mode after a successful read? Success proves access now works; checking the mode also shows that the repair did not grant unnecessary access. The next lab repeats this reasoning with explicit before/after checks.

rm -- "$study_access/config/settings.txt"
rmdir "$study_access/config" "$study_access"

Apply this to MicroBank

Imagine Accounts cannot open its runtime configuration. Start with the attempted path, actual process identity, parent-directory search permissions, and file access. Practise the repair on the existing harmless fixture. Record the same-user verification and what remains untested. Do not turn the hypothesis into a recursive permission change on a real MicroBank checkout.

Keep this observation in the MicroBank readiness project.

Sources

For the permission model, consult GNU Coreutils↗.