Understand Linux Filesystem Permissions

Linux filesystem access begins with identity, ownership, and mode bits. For a given file, the system selects the owner, group, or other permission class and checks the requested operation. Directories use the same r, w, and x letters, but their effects differ from regular files.

Learn to inspect this model before changing it. Do not respond to “Permission denied” with sudo or chmod 777.

Read a long listing

In a folder you own, run:

ls -ld .
ls -l

A line may look like:

-rw-r----- 1 student lab 84 Jul 30 10:15 notes.txt

Read it in parts:

The display is evidence, not the complete security model. Access control lists, security modules, mount options, immutable attributes, network filesystems, and container boundaries can add restrictions or rules. Start with ownership and mode bits, then investigate other layers if the evidence does not fit.

Understand how Linux selects a class

Linux does not add the owner, group, and other triplets together for one access check. It selects the applicable class:

1. use owner bits when the process identity matches the file owner;
2. otherwise, use group bits when the process belongs to the file’s group; or
3. otherwise, use other bits.

The Linux path_resolution(7) manual describes this selection during pathname access. Privileged processes and capabilities can alter ordinary checks, which is another reason not to test as root.

File and directory bits answer different questions

For a regular file:

• r permits reading file data;
• w permits modifying file data; and
• x permits executing it as a program when the format and other controls allow.

For a directory:

• r permits reading its list of names;
• w permits creating, removing, or renaming directory entries, usually in combination with x; and
• x permits searching or traversing the directory to reach named entries.

This distinction explains a common surprise: deleting a file depends mainly on permissions for its containing directory, not on the file’s own write bit. Do not experiment with deletion outside a disposable practice folder.

Every directory component in a path matters. A readable file can still produce “Permission denied” when the process lacks search permission on a parent directory.

Prefer symbolic permission changes while learning

GNU chmod accepts symbolic forms that name the affected class and change:

chmod u+x practice.sh
chmod g-w notes.txt
chmod o-r private.txt

• u, g, and o mean owner, group, and other;
• + adds, - removes, and = replaces permissions; and
• r, w, and x name the permission bits.

The GNU chmod manual also documents numeric modes. Numeric notation is compact, but it is easy to copy without understanding. Read it as three octal digits whose values combine read 4, write 2, and execute 1 for owner, group, and other.

For example, 640 represents rw-r-----. Do not memorize 777 as a repair command. It grants read, write, and execute bits to every class and often hides the real ownership or path problem.

Practice in a disposable directory

Create a folder inside your home directory:

mkdir -p "$HOME/linux-permissions-practice"
cd "$HOME/linux-permissions-practice"
printf '%s\n' 'practice only' > notes.txt
ls -l notes.txt

Predict the next listing, then remove group and other write permission with a symbolic change:

chmod go-w notes.txt
ls -l notes.txt

Your system’s initial mode depends in part on the process’s creation mode mask, often called umask. Therefore, verify the starting state instead of assuming a fixed mode.

Next, add and remove only the owner’s execute bit:

chmod u+x notes.txt
ls -l notes.txt
chmod u-x notes.txt
ls -l notes.txt

This exercise observes mode changes. It does not make the text file a useful program. Do not use sudo, recursion, chown, or a shared course directory.

Diagnose permission denied

When a path fails, inspect in this order:

1. Confirm the exact path and current directory.
2. Run id to record the process identity and groups.
3. Inspect the target with ls -ld.
4. Inspect each parent directory needed to traverse the path.
5. Identify the requested operation: list, traverse, read, write, execute, create, remove, or rename.
6. Check course, shared-system, ACL, mount, or security-module policy.
7. Change the smallest justified permission only when you own the decision.

Do not change ownership or permissions on system files, package-managed files, shared repositories, or institutional directories without their documented procedure.

Common mistakes

• Treating file and directory rwx as identical.
• Adding all three permission classes together.
• Looking only at the target and ignoring parent directories.
• Assuming execute permission makes any file a valid program.
• Using sudo or chmod 777 to suppress an unexplained error.
• Running recursive chmod on a broad or unresolved path.
• Assuming mode bits are the only access-control layer.

Do this now

Complete the disposable-folder exercise. Before each chmod, write the current mode, predicted change, and reason. Afterward, compare the listing and remove the practice folder through your normal file manager only if you want to.

Log what you learned

Record only:

• Result: What did the action produce?
• Evidence: What observation, test, or source supports that result?
• Next action or unresolved question: What should happen next?

Next, use these path and permission ideas in Linux terminal and shell practice.

Further reading

• Linux path_resolution(7)
• GNU Coreutils: chmod
• Filesystem Hierarchy Standard