Filesystem and Permissions¶

By Sameer Alam · Updated 20 October 2026

What You'll Learn¶

• Where things live in the Linux directory tree, and why it matters in operations
• How ownership and rwx permissions decide who can do what
• What setuid, setgid, and the sticky bit do, and why they're security-sensitive
• How umask and ACLs work, and how to debug "Permission denied" methodically

The Directory Layout¶

Linux follows the Filesystem Hierarchy Standard. Knowing it tells you where to look during an incident.

Reading ls -l¶

$ ls -l /etc/shadow /usr/bin/passwd deploy.sh
-rw-r-----  1 root root   1284 Sep 10 09:12 /etc/shadow
-rwsr-xr-x  1 root root  64152 May 30 12:01 /usr/bin/passwd
-rwxr-x---  1 app  devops  812 Sep 14 08:40 deploy.sh

-rwxr-x---  1  app  devops  812  Sep 14 08:40  deploy.sh
│└┬┘└┬┘└┬┘     │    │
│ │  │  │      │    └── group owner
│ │  │  │      └─────── user owner
│ │  │  └── other: no access
│ │  └───── group: read and execute
│ └──────── user: read, write, execute
└────────── type: - file, d directory, l symlink

What r, w, and x Mean¶

The same letters mean different things on files and directories. Most permission surprises come from the directory column.

Two consequences worth remembering:

• To read /srv/app/config.yml, a user needs x on /srv, /srv/app, and r on the file.
• Anyone with w on a directory can delete files in it, even files they don't own — unless the sticky bit is set.

Changing Ownership and Modes¶

sudo chown app:devops deploy.sh      # user and group
sudo chown -R app:app /srv/app       # recursively

chmod 750 deploy.sh                  # rwx r-x ---
chmod u+x,g-w,o= deploy.sh           # symbolic form: add, remove, set
chmod -R g+rX /srv/app               # capital X: execute only on directories
                                     # and files that are already executable

Avoid chmod 777. It "fixes" a permission error by letting every process on the machine modify the file.

Special Bits¶

# A shared directory where everything stays in the devops group
sudo mkdir /srv/shared
sudo chown root:devops /srv/shared
sudo chmod 2775 /srv/shared          # setgid + rwxrwxr-x

# Audit setuid and setgid binaries — unexpected entries are a red flag
sudo find / -xdev -perm /6000 -type f -exec ls -l {} + 2>/dev/null

umask: Default Permissions for New Files¶

New files start from 666 and directories from 777, and umask removes bits.

$ umask
0022          # new files 644, new directories 755

$ umask 027   # new files 640, new directories 750

Set a service's umask in its systemd unit (UMask=0027) rather than relying on a login shell default.

ACLs: Permissions for More Than One Group¶

Standard modes allow one owner and one group. Access control lists add named users and groups.

sudo apt install -y acl

# Let the "monitoring" group read application logs without changing ownership
sudo setfacl -R -m g:monitoring:rX /var/log/app
# Default ACL: files created later inherit it
sudo setfacl -R -d -m g:monitoring:rX /var/log/app

getfacl /var/log/app

A + at the end of the mode in ls -l (drwxr-x---+) tells you an ACL is present.

Immutable Files¶

sudo chattr +i /etc/resolv.conf      # nobody, including root, can modify or delete it
lsattr /etc/resolv.conf
sudo chattr -i /etc/resolv.conf

Useful to stop automation from overwriting a critical file — and a classic cause of confusing "Operation not permitted" errors when someone forgets it's set.

Debugging "Permission denied"¶

Work through the checks in order:

# 1. Who is the process actually running as?
ps -o user,group,pid,cmd -C nginx
id app

# 2. Check every directory in the path, not just the file
namei -l /srv/app/config/app.yml

# 3. Check for ACLs and attributes
getfacl /srv/app/config/app.yml
lsattr /srv/app/config/app.yml

# 4. Check mandatory access control
getenforce 2>/dev/null                            # SELinux (RHEL family)
sudo ausearch -m avc -ts recent 2>/dev/null
sudo aa-status 2>/dev/null                        # AppArmor (Ubuntu)
sudo journalctl -k | grep -i apparmor | tail

# 5. Check the mount options
findmnt -T /srv/app                               # look for ro or noexec

namei -l is the fastest win: it prints the owner and mode of every path component, so a missing x on a parent directory stands out immediately. If step 4 shows a denial, SELinux and AppArmor explains how to fix it without disabling either.

Paste your own namei -l and id output below. The walker applies the kernel's rules to every component and names the one that blocks you:

What Most Engineers Miss¶

• Only one class is checked, and the first match wins. If you own a file, only the owner bits apply. A file with mode ----rw-rw- is unreadable to its owner and readable by everyone else. The kernel doesn't fall through to the more generous group or other bits.
• Deleting a file is a change to the directory. With w and x on the directory you can delete a read-only file you don't own; rm only asks first ("remove write-protected regular file?"). The sticky bit is the only thing that stops it, which is why /tmp is drwxrwxrwt.
• Root still needs an execute bit. Root bypasses read and write checks, but exec of a file with no x bit anywhere fails even for root. A script with --x and no r fails for everyone else, because the interpreter has to read it; bash script.sh needs only r.
• New group membership needs a new login. usermod -aG docker alice changes /etc/group, not the groups of processes already running. id in the same shell shows the old list. Log out and in, run newgrp docker, or restart the service. A running process's groups are in grep Groups /proc/<pid>/status.
• Numeric chmod keeps setgid on directories. GNU chmod 755 dir leaves an existing setgid bit set. To clear it you need chmod 00755 dir, chmod g-s dir, or chmod =755 dir.
• noexec mounts win over modes. On /tmp or /dev/shm mounted noexec, ./script fails with Permission denied (exit status 126) however you set the bits. findmnt -T <path> shows the mount options.

Common Mistakes¶

• Running chmod -R 777 to fix an error, and turning a single misconfiguration into a machine-wide security hole.
• Checking the file's permissions but not the parent directories' execute bit.
• Forgetting that sudo in front of a redirect doesn't apply to the redirect: sudo echo x > /etc/file fails; use echo x | sudo tee /etc/file.
• Deploying files as root with 600, then wondering why the service user can't read them.
• Ignoring SELinux or AppArmor denials and disabling them entirely instead of fixing the label or profile.

Check Yourself¶

Interview Questions¶

• What does the execute bit mean on a directory?
• A user has rw on a file but still gets "Permission denied" when reading it. What do you check?
• What is setgid on a directory used for?
• Why is the sticky bit set on /tmp?
• How would you give a second group read access to a directory without changing its owner?

Next¶

Continue to Processes and Signals.