Linux Permissions, ACLs, and Special Bits

Linux path · AdministrationAvailable

Diagnose access safely and grant the smallest useful permission instead of solving every error with root.

Difficulty: Intermediate
Time: 75 min
Practice: Repair a shared project directory
Assessment: Knowledge check

Before you start

Who is this for?

For Linux learners who can navigate the filesystem and want to reason about ownership, modes, and inherited access.

Prerequisites

Linux Essentials
Basic shell use

What you'll be able to do

Read symbolic and numeric modes
Explain directory execute permission
Use ownership and groups
Recognise special-bit risks
Inspect and modify ACLs deliberately

Practical outcome

You can correct a shared-directory access issue while preserving least privilege.

1. The three permission classes

A file mode has permissions for owner, group, and others. For a regular file, r reads content, w changes content, and x executes it. For a directory, r lists names, w creates or removes directory entries, and x permits traversal and access to known names.

ls -l report.txt
stat report.txt
id

The mode -rwxr-x--- means the owner can read, write, and execute; the group can read and execute; others have no access. Numeric mode 750 means rwxr-x--- because read is 4, write is 2, and execute is 1.

2. Ownership and safe changes

chown alice:project report.txt
chmod 640 report.txt
chmod g+w shared/

Check the current owner, group, parent directories, and mount options before changing anything. Numeric modes are read as owner, group, and others: 777 is rwxrwxrwx, while 707 is rwx---rwx. Both grant write access to everyone outside the group, which is usually a sign that the access model needs redesigning rather than a safe fix.

Interactive exercise

Linux permission mode decoder

r = 4 · w = 2 · x = 1

Enter a three-digit mode such as 777 or 707. You can also enter a four-digit mode such as 4755 to include SUID, SGID, or the sticky bit.

Numeric mode

Use only octal digits from 0 to 7.

For a shared project directory, a group, set-group-ID directory, and a documented default policy are usually clearer than making everything world-writable.

3. Special bits

SUID on a file: the process runs with the file owner’s effective identity. Review these files carefully; a writable SUID program is a serious risk.
SGID on a directory: new entries inherit the directory’s group, which is useful for team directories.
Sticky bit on a directory: users can normally remove only their own entries, even when the directory is shared. /tmp is a common example.

Inspect them with find in a system you own and understand what each result does before changing it.

4. ACLs for exceptions

Traditional modes express one owner and one group. ACLs can grant a named user or additional group a precise exception:

getfacl project.txt
setfacl -m u:bob:r project.txt
setfacl -m g:reviewers:rx project-dir
getfacl project-dir

The effective permission can be limited by the ACL mask. Always inspect the resulting ACL and test as the intended account. Remove an exception deliberately with setfacl -x when it is no longer needed.

5. Troubleshoot access in order

Confirm the exact path and whether the error is read, write, execute, or traversal.
Use namei -l /path/to/item to inspect every parent directory.
Check owner, group, mode, ACL, and effective user with id, stat, and getfacl.
Check the process identity and service confinement such as systemd or a container.
Make the smallest change, retest, and record the reason.

Practical exercise

Create a disposable project directory with an editors group. Allow group members to create and modify project files, prevent unrelated users from reading them, and preserve group ownership for new files. Add one read-only ACL exception, test it as two accounts, and remove it afterward.

What you should be able to do now

You should be able to explain every permission change, distinguish directory traversal from file reading, and use ACLs only when owner/group modes are not expressive enough.