December 7 2022

Linux ACLs. What are Linux ACLs and what are they for?

Overcome Linux filesystem limitations with POSIX-standard Linux Access Control Lists

Linux-ACL-Access-Control-List

Linux access control lists, known as Access Control Lists (ACLs), are a critical tool for achieving more detailed and granular control of permissions within the Linux file system. While they may seem complex at first, ACLs are essential for effectively managing permissions, especially in a modern enterprise environment where it is crucial to determine who can access specific information.

In the past, access to Linux file systems was managed through a more general and less specific permission system. However, with the evolution of business needs, it has become increasingly important to have finer and more personalized access control. ACLs, an extension of traditional permission management in Unix, respond to this need.

It is important to note that the term “ACL” can have different meanings depending on the context. While in Linux it specifically refers to managing file system permissions, in other areas, such as in the management of access to HTTP services, indicates the control of access to specific services or resources. Although the acronym remains the same, its meaning varies depending on the context of use.

From a historical point of view, POSIX proposed some drafts (POSIX 1003.1e and POSIX 1003.2c) to extend permission management in Unix systems, but these were not finalized. However, many of these extensions have been published and adopted by various Unix systems, including GNU/Linux systems. Extensions called “ACL”, or “ACL POSIX” in some contexts, represent only a part of these proposals and are particularly relevant for permission management in GNU/Linux systems. This chapter focuses on the description and implementation of ACLs in such systems.

 

Review the basics of permissions on Linux

The Linux filesystem offers us three types of permissions. Here is a simplified review:

  • U ser (or user owner)
  • G group (or owning group)
  • Others (all the others)

 

With these permissions, we can grant three (actually five, but we'll get to that in a minute) types of access:

  • Read _
  • Write _
  • X cut

These levels of access are often adequate in many cases. Suppose you have a directory where your accounting department files reside. You can set these permissions to:

drwxrwxr-x  2 accounting accounting  12 Jan  8 15:13

The accounting service user (the owner of the user) can read and write to the directory and the members of the accountinggroup (or owning group) can read and write. Others (users not in the accounting department) can, however, see and run what's inside, which some might think is a bad idea.

So, we could change the permissions to this:

drwxrwx---  2 accounting accounting  12 Jan  8 15:13 .

This way other users who are neither owners of the folder nor members of the group will be able to do anything, as no read, write or execute permissions are specified.

Enable ACL support on Linux

To enable support for access control lists (ACLs) on Linux, specific work is required on the file system configuration through the /etc/fstab. This file, located in the path /etc/fstab, plays a crucial role in managing Linux systems, as it defines how hard drives or partitions should be automatically mounted by the operating system at startup and which mounting options should be applied.

The file /etc/fstab contains a series of entries, each representing a storage device or partition, and specifies how these are to be integrated into the global file system. These entries include details such as the device's unique identifier, the mount point in the file system (i.e. the location where the contents of the device will be accessible), the file system type (such as ext4, xfs, btrfs, etc.), and a number of mounting options.

To enable ACLs, it is essential to add the option acl to the relevant entries in the file /etc/fstab. This addition tells the system that support for ACLs should be enabled when mounting the specified file system or partition. Without this specification, ACLs could not be properly applied or managed on that particular file system or partition, thus limiting the ability to fine-tune file permission administration.

fstab Configuration Example with ACLs Enabled

Here is an example of what an entry in the file might look like fstab with ACLs enabled:

UUID=1234abcd-12ab-34cd-56ef-1234567890ab /example ext4 defaults,acl 0 2

In this example, we mount a partition with UUID 1234abcd-12ab-34cd-56ef-1234567890ab at the mounting point /example with the file system ext4. The option defaults applies a set of predefined mounting options, while acl Explicitly enable support for ACLs.

Considerations on Different File Systems

It is important to note that while file systems like ext3 ed ext4 require explicit enabling of ACLs via fstab, other modern file systems like XFS o Btrfs have ACL support enabled by default. This means that for the latter file systems it is not necessary to modify the file fstab to enable ACLs, unless you want to change the default settings.

If you are wondering which filesystem is best suited to your needs, read our article on the subject: Guide to Filesystems for Linux

Viewing the current ACL

Let's imagine a scenario where we have an accounting intern named Kenny, who needs access to certain files, perhaps those of Fred, his manager. Or, consider a situation where Sales needs access to accounting files owned by Fred to create invoices for Fred's team to bill customers. However, we don't want the sales team to have access to other reports generated by Fred's team. These situations pose a challenge in terms of permission management: in a standard permission system, each file and directory can have only one owner and a group of associated users. It is in these circumstances that Linux Access Control Lists (ACLs) become particularly useful.

ACLs allow us to assign a more detailed and specific set of permissions to a file or directory, without necessarily having to change the underlying permissions and ownership. In practice, they offer us the possibility to "add" access for other users or groups, in addition to those already existing.

To view the current ACL of a file or directory, we use the command getfacl. For example:

[root]# getfacl /accounting getfacl: Removing leading '/' from absolute path names # file: accounting # owner: accounting # group: accounting user::rwx group::rwx other::---

In this example, we can see that there are currently no additional ACLs in this directory, as the only permissions listed are the standard permissions for user, group, and others. In this specific case, it is normal to expect this situation, especially if the directory was just created in a test environment and no other operations were performed other than assigning ownership.

 

 

So, let's start by adding a default ACL.

Setting an ACL on Linux

Configuring Access Control Lists (ACLs) in Linux provides significant flexibility in managing file permissions. The syntax for setting an ACL is structured as follows:

setfacl [option] [action/specification] file

The “action” option can be -m (edit) or -x (remove), and the specification indicates the user or group followed by the permissions you want to set. For example, to set a default ACL on a directory, we use the option -d (default). The following command sets the default ACL on the directory /accounting:

[root]# setfacl -d -m accounting:rwx /accounting

After running this command, we can view the default ACLs for that directory with:

[root]# getfacl /accounting # output: # file: accounting # owner: accounting # group: accounting user::rwx group::rwx other::--- default:user::rwx default:user:accounting:rwx default :group::rwx default:mask::rwx default:other::---

Scenarios for Using ACLs

The syntax for setting an ACL on Linux is generally structured as follows:

setfacl [option] [action/specification] file

The “action” can be -m (edit) or -x (removal). The “specification” refers to the user or group followed by the permissions you want to set. In this example, we will use the option -d (default). To set the default ACL for a directory, you will run the command:

[root]# setfacl -d -m user:accounting:rwx /accounting

After running this command, we can check the default ACLs for that directory:

[root]# getfacl /accounting [root]# getfacl: Removing leading '/' from absolute path names # file: accounting # owner: accounting # group: accounting user::rwx group::rwx other::--- default: user::rwx default:user:accounting:rwx default:group::rwx default:mask::rwx default:other::---

Now suppose Fred creates a file in that directory:

[fred]$ touch test
[fred]$ls -la
total 0
drwxrwx---+ 2 accounting accounting 18 Jan 8 17:51 .
dr-xr-xr-x. 18 root root 262 Jan 8 15:13 ..
-rw-rw----+ 1 fred accounting 0 Jan 8 17:51 test
[fred]$ getfacl test
# file: test
# owner: fred
# group: accounting
user::rw-
user:accounting:rwx #effective:rw-
group::rwx #effective:rw-

If instead Kenny tries to create a file, since he is not part of the group accounting, he will not have permission. However, we want Kenny to have a positive work experience, so we grant him access to the directory accounting and we allow it to create new files:

[root@lab1 accounting]# setfacl -m user:kenny:rwx /accounting
[root]# getfacl .
# files: .
# owner: accounting
# group: accounting
user::rwx
user:kenny:rwx

But if we don't want Kenny to create files in the directory accounting, but only that he reads the existing files and creates new files in his personal folder, we can set his permissions like this:

[root@lab1 accounting]# setfacl -m user:kenny:r-x /accounting
[root]# getfacl .
# files: .
# owner: accounting
# group: accounting
user::rwx
user:kenny:r-x

We then create a personal folder for Kenny, give it ownership, and make the group accounting owner of the group, so that other members of the group can see what's in it:

[root@lab1 accounting]# mkdir ./kenny [root]# chown kenny:accounting ./kenny [root]# getfacl ./kenny # file: kenny # owner: kenny # group: accounting user::rwx group::rwx

Now Kenny can see the directory accounting, but can only create files in its own folder:

[root@lab1 accounting]# on kenny
[kenny]$ touch test
touch: cannot touch 'test': Permission denied
[kenny]$ cd ./kenny
[kenny]$ touch test
[kenny]$ls
test

If we give Kenny a promotion to lead reviewer and want his work to remain confidential, we can limit access to Fred:

[root]# setfacl -m user:fred:- ./kenny [root]# getfacl ./kenny # file: kenny # owner: kenny # group: accounting user::rwx user:accounting:--- user:fred: ---

What if we don't want anyone but Kenny to see his work?

[root]# setfacl -m group:accounting:- ./kenny [root]# getfacl ./kenny # file: kenny # owner: kenny # group: accounting user::rwx group:accounting:---

Conclusion: Understanding and Applying ACLs on Linux

Considering their complexity and versatility, it is strongly recommended that you dedicate time to reading and understanding the pages of the manual (man pages) For setfacl e getfacl. These pages offer a complete and detailed guide on how to use these tools, including the various options and flags available, providing practical examples and in-depth explanations.

In addition to the basic features, setfacl e getfacl they offer a number of advanced options that can be extremely useful in specific scenarios. For example, you can configure default ACLs for new directories and files in a directory, or manage ACL masks that affect actual permissions.

Experiment in a Controlled Environment

To fully understand how ACLs work, it's best to experiment in a safe testing environment. Creating different scenarios, such as managing permissions for different users and groups, can help visualize how ACLs affect access to files and directories. This type of practice is critical for developing solid intuition about how and when to use ACLs in real-world contexts.

Practical Applications

ACLs can be especially useful in multi-user environments, such as corporate servers, where different departments or teams need specific access to certain files. They are also essential for data security, allowing you to restrict access to sensitive information and ensuring that only authorized users can modify or view certain files.

Take Best Practices into Consideration

When working with ACLs, it is important to follow best practices, such as ensuring that you do not grant excessive permissions that could compromise system security. It's also crucial to keep track of changes you make, especially in production environments, to prevent any access or security issues.

Conclusion

In conclusion, while ACLs may initially seem intimidating due to their complexity, once understood, they prove to be an indispensable tool for sophisticated and detailed permission management in Linux. Spend time understanding and practicing them to fully exploit their potential, making your system safer, more efficient and suited to the specific needs of your work environment.

Do you have doubts? Don't know where to start? Contact us!

We have all the answers to your questions to help you make the right choice.

Chat with us

Chat directly with our presales support.

0256569681

Contact us by phone during office hours 9:30 - 19:30

Contact us online

Open a request directly in the contact area.

INFORMATION

Managed Server Srl is a leading Italian player in providing advanced GNU/Linux system solutions oriented towards high performance. With a low-cost and predictable subscription model, we ensure that our customers have access to advanced technologies in hosting, dedicated servers and cloud services. In addition to this, we offer systems consultancy on Linux systems and specialized maintenance in DBMS, IT Security, Cloud and much more. We stand out for our expertise in hosting leading Open Source CMS such as WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart and Magento, supported by a high-level support and consultancy service suitable for Public Administration, SMEs and any size.

Red Hat, Inc. owns the rights to Red Hat®, RHEL®, RedHat Linux®, and CentOS®; AlmaLinux™ is a trademark of AlmaLinux OS Foundation; Rocky Linux® is a registered trademark of the Rocky Linux Foundation; SUSE® is a registered trademark of SUSE LLC; Canonical Ltd. owns the rights to Ubuntu®; Software in the Public Interest, Inc. holds the rights to Debian®; Linus Torvalds holds the rights to Linux®; FreeBSD® is a registered trademark of The FreeBSD Foundation; NetBSD® is a registered trademark of The NetBSD Foundation; OpenBSD® is a registered trademark of Theo de Raadt. Oracle Corporation owns the rights to Oracle®, MySQL®, and MyRocks®; Percona® is a registered trademark of Percona LLC; MariaDB® is a registered trademark of MariaDB Corporation Ab; REDIS® is a registered trademark of Redis Labs Ltd. F5 Networks, Inc. owns the rights to NGINX® and NGINX Plus®; Varnish® is a registered trademark of Varnish Software AB. Adobe Inc. holds the rights to Magento®; PrestaShop® is a registered trademark of PrestaShop SA; OpenCart® is a registered trademark of OpenCart Limited. Automattic Inc. owns the rights to WordPress®, WooCommerce®, and JetPack®; Open Source Matters, Inc. owns the rights to Joomla®; Dries Buytaert holds the rights to Drupal®. Amazon Web Services, Inc. holds the rights to AWS®; Google LLC holds the rights to Google Cloud™ and Chrome™; Microsoft Corporation holds the rights to Microsoft®, Azure®, and Internet Explorer®; Mozilla Foundation owns the rights to Firefox®. Apache® is a registered trademark of The Apache Software Foundation; PHP® is a registered trademark of the PHP Group. CloudFlare® is a registered trademark of Cloudflare, Inc.; NETSCOUT® is a registered trademark of NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, and Kibana® are registered trademarks of Elastic NV Hetzner Online GmbH owns the rights to Hetzner®; OVHcloud is a registered trademark of OVH Groupe SAS; cPanel®, LLC owns the rights to cPanel®; Plesk® is a registered trademark of Plesk International GmbH; Facebook, Inc. owns the rights to Facebook®. This site is not affiliated, sponsored or otherwise associated with any of the entities mentioned above and does not represent any of these entities in any way. All rights to the brands and product names mentioned are the property of their respective copyright holders. Any other trademarks mentioned belong to their registrants. MANAGED SERVER® is a trademark registered at European level by MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italy.

Back to top