Linux File Permissions Guide

File permissions are the first line of defense on any Linux server. A misconfigured permission set can expose sensitive data, allow privilege escalation, or compromise your entire ServerRaja cloud deployment. This guide explores Linux permissions from the basics to advanced ACLs, with security-focused best practices tailored for production cloud environments.

Understanding Permission Basics

Every file and directory in Linux has three permission categories: owner (user), group, and others. Each category can have read (r=4), write (w=2), and execute (x=1) permissions. When you run `ls -la`, the output like `-rwxr-xr--` breaks down as: regular file, owner has read+write+execute (7), group has read+execute (5), others have read-only (4). The numeric equivalent is `chmod 754 file.txt`.

# View permissions in numeric and symbolic format
stat -c '%a %U:%G %n' /etc/nginx/nginx.conf

# Common permission sets chmod 644 file.txt # Owner rw, group r, others r (standard files) chmod 755 directory/ # Owner rwx, group rx, others rx (standard directories) chmod 600 secret.key # Owner rw only (sensitive files) chmod 700 ~/scripts/ # Owner rwx only (private scripts) ```

Ownership with chown and chgrp

Ownership determines which user and group control a file. The `chown` command changes both: `chown user:group file`. The `-R` flag applies recursively. On a ServerRaja web server running Nginx or Apache, the web content typically needs ownership by `www-data` (Debian/Ubuntu) or `apache` (CentOS). Wrong ownership is the number one cause of "403 Forbidden" errors.

# Fix web directory ownership
chown -R www-data:www-data /var/www/html

# Change only group ownership chgrp -R developers /var/www/html/app

# Verify ownership changes ls -la /var/www/html/ ```

Special Permission Bits

Beyond basic permissions, Linux offers three special bits that affect how files and directories behave in important ways.

SUID (Set User ID)

When SUID is set on an executable file (shown as `s` in the owner execute position), it runs with the file owner's privileges regardless of who executes it. The `passwd` command uses SUID so regular users can change their own password. Set it with `chmod u+s program` or `chmod 4755 program`. Be extremely cautious with SUID — any vulnerability in a SUID root binary is a privilege escalation vector.

SGID (Set Group ID)

On files, SGID runs the program with the file's group privileges. On directories, SGID causes new files to inherit the directory's group rather than the creating user's primary group. This is invaluable for shared project directories:

# Create a shared directory where all files inherit the 'webteam' group
mkdir /var/www/project
chown root:webteam /var/www/project
chmod 2775 /var/www/project

# Now any file created here will belong to 'webteam' group ```

Sticky Bit

The sticky bit on a directory (shown as `t` at the end, like `drwxrwxrwt`) prevents users from deleting files they do not own, even if they have write permission on the directory. The `/tmp` directory uses this. Set it with `chmod +t /shared/directory` or `chmod 1777 /shared/directory`.

Access Control Lists (ACLs)

Standard Unix permissions only allow one owner, one group, and others. ACLs extend this to set permissions for multiple specific users and groups. Enable ACLs on ServerRaja cloud storage (they are usually enabled by default on ext4 and XFS).

# Grant read access to a specific user
setfacl -m u:deployer:r /etc/app/config.yml

# Grant read-write to a group on a directory tree setfacl -R -m g:developers:rwX /var/www/html/app

# Set default ACLs for new files in a directory setfacl -d -m g:developers:rwX /var/www/html/app

# View all ACLs on a file getfacl /etc/app/config.yml

# Remove a specific ACL entry setfacl -x u:deployer /etc/app/config.yml ```

Security Best Practices

Follow these practices to keep your ServerRaja server secure:

**Principle of Least Privilege**: Never give more permissions than needed. A PHP application rarely needs 777 permissions. Use 640 for config files and 750 for directories.

**Protect Sensitive Files**: SSH keys, database passwords, API tokens, and TLS certificates should be `chmod 600` and owned by root. The `~/.ssh/` directory should be `chmod 700` with `authorized_keys` at `chmod 600`.

# Lock down SSH directory
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub
chmod 644 ~/.ssh/known_hosts

**Avoid World-Writable Directories**: Find and audit them with `find / -type d -perm -002 2>/dev/null`. Remove world-write with `chmod o-w directory` unless sticky bit is set.

**Audit SUID and SGID Binaries**: Periodically scan with `find / -perm /6000 -type f 2>/dev/null`. Remove SUID/SGID from binaries that do not need it: `chmod u-s /path/to/binary`.

**Use umask Wisely**: The default `umask 022` creates files with 644 permissions. For more restrictive defaults, set `umask 027` in `/etc/profile` which creates files as 640 and directories as 750.

**Immutable Flag**: For critical configuration files that should never be changed accidentally, use the immutable attribute: `chattr +i /etc/passwd`. Even root cannot modify an immutable file without first removing the flag with `chattr -i`.

Common Permission Mistakes

Running `chmod 777` on anything is almost always wrong. It gives every user full control. Instead, identify exactly who needs access and grant only what is necessary. Running `chmod -R 777 /var/www` is especially dangerous on a production server. If your application says it needs 777, the real fix is usually correcting the user or group ownership so the web server process can write with 750 or 770 permissions instead.

Key Takeaways

**Never use `chmod 777`** — it gives every user full control and is almost always a sign of incorrect ownership; fix ownership with `chown`/`chgrp` instead.
**SUID, SGID, and sticky bit** are powerful but dangerous — SUID binaries run as the file owner (often root), so audit them regularly with `find / -perm -4000`.
**ACLs** provide fine-grained access beyond user/group/other — use `setfacl` for scenarios where multiple users need different permissions on the same file.
**Set `umask 027`** system-wide to create files as 640 and directories as 750 by default, blocking world-readable access from the start.
**Use `chattr +i`** on critical config files like `/etc/passwd` to prevent accidental or malicious modification, even by root.

Linux File Permissions Deep Dive: Security Best Practices for Cloud Servers