Linux / Basic: command-line foundations / Lesson 4

Reason about permissions and ownership

Read file modes, distinguish file access from directory access, and choose narrow permissions for a private lab.

About 4 min readContent reviewed 2026-10-23

On this page

Lesson goals

Decode symbolic and octal permission modes.
Explain directory traversal and deletion checks.
Use umask without assuming it grants permissions.

Access depends on identity and object

Each file has an owner user ID, group ID, and mode bits. The familiar user, group, and other classes describe which permission set applies. The kernel normally selects the owner class when identities match, otherwise the matching group class, otherwise other. It does not combine all three classes to rescue a denied request. Supplemental groups also matter. id displays your current process credentials, while ls -l provides a readable ownership and mode view. Names are labels resolved from numeric IDs, so numeric inspection helps when account databases differ.

Files and directories interpret bits differently

For a regular file, read permits reading content, write permits modifying it, and execute permits attempting execution. For a directory, read lists names, execute searches through known names, and write permits changing directory entries when the other required checks also pass. Deleting a file primarily changes its parent directory, so a read-only file may still be removable by someone with suitable parent access. Every parent directory in a path needs search permission. A file’s own readable mode cannot compensate for an inaccessible ancestor.

Translate modes into a policy

Symbolic chmod operations name the affected classes and permissions. u=rw,go= gives the owner read and write access and clears group and other permissions. Numeric modes sum read=4, write=2, execute=1 for each class; 640 means owner read/write, group read, and no other access. State the intended policy before selecting a number. chmod changes the mode, while ownership changes use different tools and often require administrative authority. Never solve an unexplained access problem by granting everyone all permissions.

bash Give a synthetic note private access

lab=$(mktemp -d)
printf '%s\n' 'synthetic private note' > "$lab/note.txt"
chmod u=rw,go= "$lab/note.txt"
stat -c '%a' "$lab/note.txt"

Expected output

The owner-created lab file receives mode 600. This example changes only the new temporary note, and stat uses GNU syntax.

umask removes creation permissions

Programs request an initial creation mode, and umask normally removes specified permission bits from that request. Common regular-file creation requests are 666 and directory requests 777, but applications can request less. With umask 027, those requests become 640 and 750. It is a bitwise mask, not ordinary decimal subtraction, and it never adds permissions that the program did not request. Existing files are unaffected. A parent directory’s default ACL can change how creation permissions are derived; the intermediate access-control lesson explores that case.

bash Observe a mask inside a subshell

lab=$(mktemp -d)
(umask 027; mkdir "$lab/team"; : > "$lab/team/item.txt")
stat -c '%a' "$lab/team" "$lab/team/item.txt"

Expected output

750
640

On a normal lab filesystem without an inherited default ACL, the new directory is 750 and the new file is 640. The parent shell’s mask does not change.

Recognize additional access controls

Mode bits are the starting model, not the complete security system. ACLs can grant named users access, mandatory controls such as SELinux or AppArmor can impose further restrictions, and a read-only mount can prevent writes even with writable mode bits. The sticky bit on a shared directory restricts who can remove or rename entries; it does not make every file private. Set-user-ID and set-group-ID have special execution or inheritance meanings and deserve separate review. Diagnose the actual denied operation rather than changing unrelated controls.

Common errors and fixes

Permission denied despite file read permission

Why it happens: A parent directory lacks search access or another control denies access.
How to fix it: Inspect the full path and applicable policy.
Prevent it next time: Evaluate the requested operation end to end.

Using 777 as a general repair

Why it happens: The required user and action were never identified.
How to fix it: Grant only the needed class and permission.
Prevent it next time: Write an access policy before changing a mode.

Expecting umask to modify existing files

Why it happens: A creation-time mask was confused with chmod.
How to fix it: Inspect existing modes and modify only selected lab objects.
Prevent it next time: Separate creation defaults from later permission management.

Check your understanding

1. Decode 750 on a directory and explain what a group member can do.

Show worked solution

The owner has read, write, and search; group has read and search; others have none. A group member can list names and traverse the directory, but cannot create or remove entries through this mode alone. File content access still depends on each file.

2. A program requests mode 600 with umask 022. Predict the result and justify it.