Difference between Traditional Linux permissions and ACL

Where necessary, you may need to have access to a VPS server so you can follow how to implement the steps in this article.  You can get a cheaper VPS Server from Contabo with 4vCPU cores, 8GM RAM, and 32TB Bandwidth for less than $5.50 per month. Get this deal here now

Table of Contents

Cloud VPS S

$5.50 Monthly
  • 4 vCPU Cores | 8GB RAM


$15.50 Monthly
  • 6 vCPU Cores | 16GB RAM


$17.50 Monthly
  • 8 vCPU Cores | 24GB RAM

Linux’s robust security model employs various mechanisms to control access to files and directories. Two prominent methods are traditional permissions and Access Control Lists (ACL).


Traditional Linux permissions are based on the owner, group, and others, each having specific read, write, and execute permissions. These permissions are represented by letters – ‘r’ for read, ‘w’ for write, and ‘x’ for execute. Let’s take a look at an example using the ls command:

$ ls -l myfile.txt
-rw-r--r-- 1 user1 users 1024 Mar 5 10:00 myfile.txt

In this output, the first set of characters represents the owner’s permissions, the second set for the group, and the third for others.

While traditional permissions provide a simple and effective way to manage access, they might fall short in scenarios requiring more granular control. This is where ACL comes into play. ACL extends the basic permission model, allowing users to define specific access rules for individual users or groups.

Let’s add an ACL to the previous example using the setfacl command:

$ setfacl -m u:user2:rw myfile.txt

This command grants read and write permissions to ‘user2’ on ‘myfile.txt’. The extended ACL information can be viewed using the getfacl command:

$ getfacl myfile.txt
# file: myfile.txt
# owner: user1
# group: users

Here, you can see the traditional permissions along with the additional ACL entry for ‘user2’.

Traditional permissions operate at a basic level, applying the same rules to the owner, group, and others. ACL, on the other hand, allows for fine-grained control, enabling users to specify permissions for individual entities.

In the context of Linux permissions, “granularity” refers to the level of detail or precision in specifying access controls. More specifically:

Traditional Permissions Granularity:

Traditional permissions in Linux operate with a relatively coarse level of granularity. The permissions are set for three entities: owner, group, and others. The rules are uniform for each category, applying the same set of permissions to all users within that category.

ACL (Access Control Lists) Granularity:

ACL, on the other hand, introduces a finer level of granularity. It allows users to define specific access rules for individual users or groups. With ACL, you can set permissions for a particular user that differ from the group permissions or the default owner permissions, providing more detailed control over access to files and directories.


Securing data and ensuring proper access controls are essential in the Linux environment. Traditional Linux permissions have long been the stalwart in this domain, but as systems grew more complex, Access Control Lists (ACLs) emerged to provide a more nuanced solution.

Traditional Linux Permissions: Simplicity in Structure

Traditional permissions operate on a simple and structured model. The permissions—read (r), write (w), and execute (x)—are assigned to three entities: owner, group, and others. The structure is clear, with each entity having predefined and uniform permissions.

Consider the following ls command example:

$ ls -l myfile.txt
-rw-r--r-- 1 user1 users 1024 Mar 5 10:00 myfile.txt

In this output, the structure is straightforward: ‘rw-‘ for the owner, ‘r–‘ for the group, and ‘r–‘ for others.

ACLs: Introducing Nuance and Flexibility

Access Control Lists (ACLs) bring a new layer of complexity, introducing the ability to define permissions for specific users or groups individually. While powerful, this added capability increases the intricacy of access control.

Let’s add an ACL to the previous example using the setfacl command:

$ setfacl -m u:user2:rw myfile.txt

In this command, ‘user2’ is granted read and write permissions, creating an additional layer of access control beyond the traditional permissions.

Traditional Permissions: A Foundation of Simplicity

Traditional permissions, with their simplicity, form a solid foundation for access control. The rules are clear, making them easy to understand and implement. However, this simplicity can become a limitation when granular control is needed.

ACLs, while providing unparalleled control, introduce a level of complexity that may be overwhelming for basic use cases. Managing and understanding ACLs necessitates familiarity with an extended set of commands and syntax.


In conclusion, the choice between traditional Linux permissions and ACLs hinges on the level of control required for a given system. Traditional permissions offer simplicity and clarity, making them suitable for straightforward scenarios. However, as systems evolve and access requirements become more intricate, ACLs step in, providing the necessary granularity at the expense of added complexity. The decision ultimately rests on striking the right balance based on the specific security needs of the Linux environment.


Hire us to handle what you want

Hire us through our Fiverr Profile and leave all the complicated & technical stuff to us. Here are some of the things we can do for you:

  • Website migration, troubleshooting, and maintenance.
  • Server & application deployment, scaling, troubleshooting, and maintenance
  • Deployment of Kubernetes, Docker, Cloudron, Ant Media, Apache, Nginx,  OpenVPN, cPanel, WHMCS, WordPress, and more
  • Everything you need on AWS, IBM Cloud, GCP, Azure, Oracle Cloud, Alibaba Cloud, Linode, Contabo, DigitalOcean, Ionos, Vultr, GoDaddy, HostGator, Namecheap, DreamHost, and more.

We will design, configure, deploy, or troubleshoot anything you want. Starting from $10, we will get your job done in the shortest time possible. Your payment is safe with Fiverr as we will only be paid once your project is completed.