Permission Forensics

stat - a hands-on Linux lab on a real virtual machine.

Diagnose and fix a permission or ownership problem that blocks a user or service (EX200 task 32). Read a file exact metadata with stat -c (name, symbolic and octal mode, owner, group), trace every component of a path with namei -l to expose a parent directory missing the execute bit, and hunt files by permission with find -perm -4000 for setuid programs. The blocking bit is usually a missing execute on a PARENT directory, invisible from the file itself. RHCSA 10 drops ACLs, so no setfacl; access is diagnosed with plain ugo/rwx, ownership, and directory execute.

A member of the devs group calls you: they cannot read /srv/team/report.txt. You look at the file and everything seems correct. The owner is right, the group is devs, the permissions are readable. You run cat on it as that user and Linux still says Permission denied. The file is innocent. Something ELSE in the path is guilty, and you cannot see it by staring at the file alone.

This is EX200 task 32: fix a permission problem that blocks a user or a service. The fix is never a wild chmod 777. It is a diagnosis. You read the exact metadata. You trace every directory the user must pass through. You find the one bit that is wrong. This lesson gives you the three forensic tools that turn Permission denied from a mystery into a one-line fix.

The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs are from a real RHEL 10 machine (AlmaLinux 10.2), captured against /srv/team, an SGID collaboration directory owned by the devs group. On the exam ACLs are gone, so there is no setfacl or getfacl here. Everything is diagnosed with plain ugo/rwx, ownership, and the execute bit on directories.

Permission forensics means reading the exact state of a file and its whole path BEFORE you change anything. You are answering four questions in order: who owns it, what group owns it, what are the mode bits, and can the user reach it through every parent directory. Only after you know all four do you pick the single smallest fix.

Three tools answer those questions. stat reads a file's exact metadata. namei -l traces the permissions of every component in a path. find -perm hunts the whole filesystem for files carrying a specific permission bit. Learn to read all three and no permission problem can hide from you.

Here is the trap that catches most engineers. To open a file, a user needs read (r) on the file itself, but to REACH the file the user needs execute (x) on every single directory in the path above it. Execute on a directory means the right to enter it and look inside. Miss that x on one parent, three levels up, and the file below is unreachable no matter how perfect its own permissions are.

That is why staring at the file lies to you. The file says -rw-r--r--, perfectly readable, while a parent directory quietly says drwxr-x--- and locks everyone but its owner and group out of the whole subtree. The tool that exposes this is namei -l, and it is the reason this lesson exists.

Start at the file. stat prints a file's full metadata, but the raw output is a wall of timestamps. The -c flag lets you format exactly the fields you want on one line: %n is the name, %A is the symbolic mode, %a is the octal mode, %U is the owner, %G is the group. That one line is your forensic snapshot.

Before you run it, decide what you expect for a shared file in the devs directory: an owner, a group of devs, and mode bits. Read the snapshot:

stat -c 'name=%n mode=%A octal=%a owner=%U group=%G' /srv/team/report.txt

prompt: [root@servera ~]# answer: stat -c 'name=%n mode=%A octal=%a owner=%U group=%G' /srv/team/report.txt output: name=/srv/team/report.txt mode=-rw-r--r-- octal=644 owner=root group=devs hint: The tool is stat with -c and a format string of %n %A %a %U %G, then the file path.

One clean line. The file is owned by root, its group is devs, and the mode is -rw-r--r--, which is octal 644. Read it: the owner can read and write, the group devs can read, everyone else can read. So a devs member CAN read this file, as far as the file itself is concerned. The file is not the problem. That is a real finding. It is exactly what pushes you to look higher up the path. stat -c turned a wall of metadata into the four facts you needed.

The %a octal shows 644 here for a plain shared file. On a directory with the SGID bit set you would see a leading digit, like 2775, and %A would show an s in the group slot. The forensic move is the same either way: stat -c with %A and %a tells you the mode both ways, symbolic for reading and octal for chmod.

The file checked out, so now walk the path. namei -l takes a full path and prints one line per component, from / all the way down to the file, each with its permissions, owner, and group. It is the single tool that shows you a locked parent directory, the thing stat on the file can never reveal.

Feed it the full path to the report. Read every line, top to bottom, and watch the directories:

namei -l /srv/team/report.txt

prompt: [root@servera ~]# answer: namei -l /srv/team/report.txt output: dr-xr-xr-x root root / drwxr-xr-x root root srv drwxrws--- root devs team -rw-r--r-- root devs report.txt hint: The tool is namei with the -l flag, then the full path: namei -l /srv/team/report.txt

Four lines, one per component. Read the third: drwxrws--- root devs team. That is the /srv/team directory. Its permissions are rwxrws---: owner root has full access, the group devs has read-write-execute (the s is the SGID bit riding on the group execute), and OTHER has nothing at all, the trailing ---. So a user who is in devs can enter team and reach the file. A user who is NOT in devs hits that --- and is stopped at the directory. It does not matter how readable report.txt is below. namei -l just showed you the exact gate. If the caller cannot read the file, confirm they are actually in the devs group.

The blocking bit is almost always the missing execute on a PARENT directory, and it is invisible from the file. A directory line like drwxr-x--- means only the owner and group can enter; everyone else is stopped there and every file beneath it becomes unreachable. When someone reports Permission denied and the file itself looks fine, run namei -l on the full path and scan the DIRECTORY lines for a missing x in the slot that user falls into.

The third tool searches instead of inspects. find -perm finds every file across the filesystem that carries a specific permission bit. The most important forensic use is hunting setuid programs: -perm -4000 matches any file with the setuid bit, a program that runs with its owner's power instead of the caller's. Auditing those is a real security task.

The -4000 form with the leading dash means match files that have AT LEAST that bit set. Sweep the filesystem for setuid programs:

find / -perm -4000 -type f

prompt: [root@servera ~]# answer: find / -perm -4000 -type f output: /usr/bin/umount /usr/bin/mount /usr/bin/chage hint: The tool is find, the start path /, then -perm -4000 to match the setuid bit, and -type f for files.

A short list of setuid programs: umount, mount, and chage all live at /usr/bin and carry the setuid bit so an ordinary user can run them with the elevated power they need. The leading dash in -4000 is the key: it means AT LEAST this bit, so it catches a setuid file whatever its other permission bits are. Drop the dash and -perm 4000 would demand the mode be EXACTLY 4000 and match almost nothing. For forensics you almost always want the leading dash: find files that carry a bit, regardless of the rest.

Scaffolding off. No command is printed this time. You have every piece you need.

A user swears their file /srv/team/report.txt is readable, and stat on the file agrees: mode 644, group devs. Yet they still get Permission denied. You suspect a parent directory in the path is the real gate. You want one command that prints the permissions, owner, and group of EVERY component from / down to the file. Then you can find the directory that blocks them. Which command traces the whole path?

prompt: [root@servera ~]# answer: namei -l /srv/team/report.txt output: dr-xr-xr-x root root / drwxr-xr-x root root srv drwxrws--- root devs team -rw-r--r-- root devs report.txt hint: It is the tool that walks a path component by component. namei, with the long -l flag, then the full path.

namei -l /srv/team/report.txt walks the path and prints a line for /, srv, team, and report.txt, each with its mode, owner, and group. The team line, drwxrws--- root devs, is where a non-devs user is stopped: OTHER has ---, so they cannot enter the directory and never reach the file. That is the forensic loop in one command: when the file looks fine, namei -l finds the parent that is not. Pair it with stat -c on the file and you can diagnose any Permission denied on the exam.

You earned this cheat sheet. Every row is a form you just ran:

The one thing to burn in for the exam: when a file looks readable but the user is still blocked, the guilty bit is a missing execute on a PARENT directory. stat -c clears the file, namei -l finds the parent, then a single chmod or chown fixes it. Remember ACLs are gone from RHCSA 10, so no setfacl.

Read the namei -l directory lines against the user who is blocked. If they are the owner, check the owner triad; if they are in the group, check the group triad; otherwise check OTHER, the last three characters. A missing x in the slot that user falls into is the gate. The fix is always the smallest change that adds exactly that bit, never chmod 777.

The practice terminal has shown you the full forensic loop: stat -c to read a file's exact owner, group, and mode in one line, namei -l to trace every directory in the path and expose the parent that blocks access, and find -perm -4000 to hunt setuid programs across the filesystem. Every one of those you typed yourself.

The file-systems module mission is where you run these against a real RHEL 10 machine. A full VM boots for you, with real files and directories whose permissions someone has broken on purpose. The mission hands you objectives that use exactly what you practiced here. A user or a service is blocked. You diagnose it with stat and namei -l, name the wrong bit, and fix it with the smallest chmod or chown. One difference from this lesson: the mission shows no commands. You read the objective, recall the forensic loop, and type it. That recall is what makes it stick on exam day.

Finish the other file-systems lessons, then go fix a real machine's broken permissions.

Practice Permission Forensics in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.