Table of contents of the article:
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 _
- e 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.
