Linux File Permissions: Mastering ACLs and Sticky Bits
Master Linux file permissions, ACLs, and the sticky bit to secure your server. Go beyond basic chmod and chown with practical, hands-on examples.
Last month, I spent about three hours debugging a production environment where a web service couldn't write to its own cache directory. The issue turned out to be a misconfigured group bit, which led me back to basics: understanding how Linux file permissions actually govern our systems.
If you’ve been relying solely on the standard user-group-others model, you’re missing out on the flexibility required for modern server management.
The Fundamentals: chmod and chown
Most of us start with chmod and chown. They are the workhorses of file management, but they are surprisingly easy to misuse.
When you run chmod 755 file.txt, you’re setting the owner to read/write/execute, and the group/others to read/execute. While this is standard, it’s often too broad for sensitive directories. If you want to audit who is actually touching those files, you might want to look into eBPF-based File Access Auditing: Track Config Changes with bpftrace to see exactly what processes are hitting your disk in real-time.
Remember:
chmod: Changes the mode (permissions) of a file.chown: Changes the ownership (user and group) of a file.
If you find yourself frequently struggling with unauthorized file changes, you should also consider File Integrity Monitoring: eBPF and Fanotify for Docker VPS to add an extra layer of visibility to your security posture.
Moving Beyond Basics: Access Control Lists
Standard linux file permissions are binary; they apply to one user and one group. What happens when you have a complex team structure where three different service accounts need write access to a single log directory?
This is where access control lists (ACLs) come in. They allow you to define fine-grained rules that go beyond the traditional UGO (User-Group-Others) model.
To check if your filesystem supports ACLs, just run mount | grep acl. If you're on a modern distro, it's almost certainly enabled. You use getfacl to view permissions and setfacl to modify them.
Bash# Give user 'web-admin' read/write access to a directory setfacl -m u:web-admin:rw /var/www/uploads # Remove the entry later setfacl -x u:web-admin /var/www/uploads
The beauty of ACLs is that they don't break the standard permissions; they augment them. You can keep your standard chmod settings for compatibility while adding specific exceptions for your CI/CD pipelines or monitoring agents.
Understanding the Sticky Bit
The sticky bit is one of those Linux features that sounds obscure until you encounter a directory like /tmp. It’s a special permission bit (represented by a t in the output of ls -l) that prevents users from deleting or renaming files they don't own, even if they have write access to the parent directory.
Without the sticky bit, any user with write access to a shared folder could delete files created by other users.
| Feature | Primary Use Case |
|---|---|
| Standard UGO | Simple personal file management |
| ACLs | Granular access for multiple users/services |
| Sticky Bit | Protecting files in shared directories like /tmp |
To set the sticky bit on a directory, use:
Bashchmod +t /shared/data
Why Security is Layered
You cannot rely on permissions alone to secure an entire application. Just like I emphasize in my guide on Laravel Authorization Guide: Managing Guest and Admin Access Easily, effective security happens at multiple levels.
Permissions at the filesystem level are your last line of defense. If a web vulnerability allows a remote code execution, having strict Linux file permissions ensures the attacker can't easily traverse your system or overwrite critical binaries.
FAQ
Q: Are ACLs slower than standard permissions? A: In practice, the performance overhead is negligible for 99% of use cases. Modern filesystems like ext4 and XFS handle ACLs extremely efficiently.
Q: Can I use ACLs on all Linux filesystems? A: Most common filesystems (ext4, XFS, btrfs) support them. If you’re using a very old or exotic filesystem, you might hit a wall, but it’s rarely an issue in modern production environments.
Q: What is the difference between SUID and the sticky bit? A: SUID allows a file to execute with the privileges of the file owner (often root). The sticky bit is strictly for directory cleanup protection. Don't confuse them; SUID can be a significant security risk if misapplied.
I’m still experimenting with how to best manage ACLs across large fleets of servers using Ansible. It can get messy if you aren't careful with idempotency. If you're starting out, stick to standard permissions until you have a genuine need for the complexity of ACLs.