Linux ACLs. What are Linux ACLs and what are they for? - 🏆 Managed Servers
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, or ACLs, can take some getting used to, but are invaluable for gaining more granular control of Linux file system permissions.

Among the challenges of administering Linux in the modern corporate environment is the expectation that we can and should manage who has access to what information. Once upon a time, the only people who needed access to Linux filesystems could be classified broadly: through Linux filesystem permissions.

The acronym «ACL» stands for Access control list and refers here to an extension of permission management, beyond the tradition of Unix systems.

As is often the case, names representing acronyms can mean different things in different contexts. In the particular case of the acronym ACL, this is also used in other situations, especially in managing access to HTTP services, where you want to regulate access to the service or particular resources. What must be understood is that the acronym ACL, even if, as an acronym, refers to the same words, represents different situations based on the context.

POSIX has produced some drafts on the possibility of extending the management of the permissions of Unix systems (POSIX 1003.1ee POSIX 1003.2c), but these works have remained unfinished. These drafts are public, and several Unix systems make some of these extensions available. The extensions referred to with the acronym ACL, or possibly with "ACL POSIX" (although they are only drafts), are only a portion of the overall set and in this chapter we want to describe in particular the implementation relating to the systems GNU/Linux.

 

Review the basics

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.

Viewing the current ACL

What if you have an accounting intern (Kenny) who needs to be able to read certain files (or even just files owned by Fred, his manager)? Or maybe people in the sales department need access too accountingowner file to create invoices for Fred's team to invoice customers, but you don't want the sales team to see the other reports generated by Fred's team. This situation can be complicated because, with regular permissions, each file and directory can only have one user and group owner at a time. This kind of situation is what Linux Access Control Lists (ACLs) were meant to fix.

ACLs allow us to apply a more specific set of permissions to a file or directory without (necessarily) changing ownership and basic permissions. They allow us to "add" access for other users or groups.

We can view the current ACL using the getfaclcommand:

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

We can see that right now there are no ACLs on this directory because the only permissions listed are for user, group and other. In this case, that was to be expected, because I just created this directory in the lab and all I did was assign ownership.

 

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

Setting up an ACL

The syntax for setting an ACL looks like this:

setfacl [option] [action/specification] file

The “action” would be -m(edit) or  -x(remove) and the spec would be the user or group followed by the permissions we want to set. In this case, we'll use the option -d(default). So, to set the default ACL for this directory, we'll run:

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

After that we can now see the default ACL information 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::---

What if Fred creates a file in that directory?

[fred]$ touch test
[fred]$ ls -la
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-

What if Kenny tries to create a file? You might be able to guess that since  kennyit is not in accountinggroup, will not have permission. But we want Kenny to have a good experience working with us, so we need to give him the ability to see what files are in the accountingdirectory and we want it to be able to create new files:

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

So far, so good. But what if we don't want this user to create files in the accountingdirectories? Instead, we just want it to read the files there and it can create new files in its folder.

We can set Kenny's access to the accountingfolder like this:

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

Now let's make Kenny his folder, give him ownership, and then make the accountinggroup the owner of the group so that other people in the accountinggroup can see what's inside:

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

You have created a folder inside the accountinguser-owned group kenny. It is now able to see the accounting folder, but it only creates files in its own folder:

[root@lab1 accounting]# su kenny
[kenny]$ touch test
touch: cannot touch ‘test’: Permission denied
[kenny]$ cd ./kenny
[kenny]$ touch test
[kenny]$ ls
test

Note that since the folder is owned by the accountinggroup, anyone in that group can post files there. Since we are dealing with an intern, this factor is probably fine. However, what if we give Kenny a promotion to lead reviewer and want to keep his work a secret from Fred?

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

What if we didn't want that no see what Kenny is working on?

[root]# setfacl -m g:accounting:- ./kenny

Note: when we want to set an ACL of group , we must specify it by prefixing g:the name of the group. For users, it just changes gin a u, but setfaclassume we're talking about a user if you put nothing there.

We still need to remove the basic permissions for the group owner so the rest of the accounting team can't snoop on Kenny's reports:

[root]# chmod g-rwx ./kenny
[root]# ls -al
total 0
drwxrwx-wx+  3 accounting accounting  44 Jan  9 16:38 .
dr-xr-xr-x. 18 root       root       262 Jan  8 15:13 ..
drwx------+  2 kenny      accounting  18 Jan  9 17:07 kenny
-rw-rw----+  1 root       root         0 Jan  9 16:33 test
-rw-rw----+  1 kenny      accounting   0 Jan  9 16:27 test2
[root]# getfacl ./kenny
# file: kenny
# owner: kenny
# group: accounting
user::rwx
user:accounting:---
user:fred:---
group::rwx  #effective:---
[root]# su jan
[jan]$ touch ./kenny/test
touch: cannot touch ‘./kenny/test’: Permission denied

We can now manage who else can see or write to Kenny's folder without changing ownership. Let's give the CEO (Lisa, who isn't a member of the accounting team and won't have access to the rest of the file) access to Kenny's stuff:

[root@lab1 accounting]# useradd lisa
[root]# setfacl -m u:lisa:rwx ./kenny
[root]# su lisa
[lisa]$ touch ./kenny/lisa
[lisa]$ ls ./kenny
lisa  test
[lisa]$ touch test
touch: cannot touch ‘test’: Permission denied
[root]# getfacl ./kenny
# file: kenny
# owner: kenny
# group: accounting
user::rwx
user:accounting:---
user:fred:---
user:lisa:rwx
group::rwx
group:accounting:---

Note again that the group owner's permissions remain fully open, but the accounting group (which is still the owner) no longer has access to that folder. So who owns it?

drwxrwx---+  2 kenny  accounting  30 Jan  9 17:16 kenny

This part is tricky. It's good to know that we can remove owner permissions without changing ownership, but you may want to consider whether this is the result you want.

Conclusion

So these are the basics. ACLs can get confusing, so I encourage you to give the man pages setfaclgetfacla good read. There are many other cool and useful things you can do with these tools, but hopefully now you understand enough to get started.

About the author

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 owns 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™; Facebook, Inc. owns the rights to Facebook®; 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 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 registered trademark at European level by MANAGED SERVER SRL Via Enzo Ferrari, 9 62012 Civitanova Marche (MC) Italy.

Back to top