File permissions in Linux

Access control that protects your Linux server in real life

Linux file permissions are one of the most important security foundations of any server — from a small VM to a production Linux VPS. Correct permissions prevent accidental deletion, reduce data leaks, and make attacks harder (because even if an attacker gets into one account, they still can’t touch everything).

This guide explains how permissions work, how to read them, and how to configure them safely using chmod, chown, groups, umask, and ACL — with practical examples for hosting and web servers.

Users, groups, and the three permission scopes

Every file and directory belongs to:

1. Owner (user) — the primary account that “owns” the file.
2. Group — a group of users who can share controlled access.
3. Others — everyone else on the system.

And there are three basic rights:

• r = read
• w = write
• x = execute

These rules are essential on any multi-user system, including hosting environments and VPS servers where multiple services and users exist side-by-side.

How to read permissions from ls -l

ls -l

Example output:

-rw-r-----  1 alice  dev  2048 Mar 10 12:00 config.php
drwxr-xr-x  2 root   root 4096 Mar 10 12:00 /var/www

Breakdown of -rw-r-----:

• First char: – is a file, d is a directory, l is a symlink.
• Next 3: rw- = owner permissions
• Next 3: r– = group permissions
• Next 3: — = others permissions

Pro tip: for deeper details (including numeric modes), use:

stat filename

Important nuance: directory permissions are NOT the same as file permissions

On directories, r/w/x behaves differently:

This is why “I can see the folder but can’t open files” happens: the directory may have r without x.

Symbolic vs numeric modes

You will see permissions in two main formats:

• Symbolic (human-readable): rwxr-xr-x
• Numeric (used with chmod): 755, 644, 600

Numeric values are sums:

• r = 4
• w = 2
• x = 1

So:

• 7 = 4+2+1 = rwx
• 5 = 4+1 = r-x
• 4 = 4 = r--
• 0 = 0 = ---

Core commands: chmod, chown, chgrp

These commands are the everyday toolkit for permissions management on Linux hosting and VPS servers.

chmod — change permissions

# Numeric mode:
chmod 644 index.html
chmod 755 script.sh

# Symbolic mode:
chmod u=rw,g=r,o=r config.ini
chmod u+x deploy.sh
chmod g+w uploads

Be careful with recursive chmod: directories and files often require different modes (e.g., 755 for dirs, 644 for files). Instead of chmod -R, it’s safer to use find:

# Set directories to 755
find /var/www/site -type d -exec chmod 755 {} \;

# Set files to 644
find /var/www/site -type f -exec chmod 644 {} \;

chown — change owner

# Change owner only
chown alice file.txt

# Change owner and group
chown alice:dev file.txt

# Recursive ownership change (use carefully!)
chown -R www-data:www-data /var/www/site

chgrp — change group

chgrp dev file.txt

Special bits: SUID, SGID, Sticky Bit

Linux includes special permission flags used for shared directories and controlled privilege behavior:

• SUID (Set User ID): executable runs with owner privileges (chmod u+s).
• SGID (Set Group ID): in directories, new files inherit the directory group (chmod g+s).
• Sticky Bit: users can’t delete files they don’t own in shared directories (common for /tmp) — chmod +t.

# Sticky bit on shared folder
chmod +t /shared

# SGID on a team directory (keeps consistent group ownership)
chmod g+s /var/www/team_project

On hosting and web servers, SGID is especially useful for team deployments where multiple users edit the same project without constantly fixing group ownership.

Default permissions: umask (and why it matters)

umask defines the default permissions for newly created files and directories. This is critical on servers: without a safe umask, new files can end up too open.

# View current umask
umask

# Example: safer defaults (common on servers)
umask 027

With umask 027 typical defaults become:

• New files: 640
• New directories: 750

ACL: granular access for specific users (beyond owner/group/others)

Sometimes you need to grant access to one user without changing owner/group. That’s when ACL (Access Control Lists) is the right tool.

# View ACL
getfacl file.txt

# Give user bob read/write access
setfacl -m u:bob:rw file.txt

# Give group qa read access
setfacl -m g:qa:r file.txt

# Default ACL for a directory (new files inherit it)
setfacl -d -m g:dev:rwX /var/www/team_project

ACL is very practical on VPS hosting where you manage multiple services/users and want strict control without constant ownership changes.

Secure permission presets you can actually use

These are common, safe starting points (adjust if your app needs different behavior):

• SSH folder: ~/.ssh → 700, keys → 600
• Web directories: 755
• Web files: 644
• Config with secrets: 600 (or 640 with controlled group)
• Uploads directory: often needs group write (avoid 777; use group strategy + SGID/ACL)

Avoid chmod 777. It’s the #1 “quick fix” that becomes a security hole — especially on shared environments and misconfigured web apps.

Monitoring changes and detecting permission problems

Permissions are only part of server security. You also need visibility:

• auditd — audit access to critical files and directories
• journalctl — inspect system logs
• lsof — see which processes use which files
• ps aux — detect suspicious processes

If you’re hosting websites or services, combining correct permissions with monitoring makes your Linux environment significantly more stable and secure.

Conclusion

File permissions in Linux are simple in concept but powerful in practice. Learn to read ls -l, use groups strategically, avoid risky recursive changes, set a safe umask, and apply ACL when you need precise control. This approach is essential on any Linux VPS and helps keep your hosting environment stable and secure.