Summary
Are you in charge of a shared file server between multiple groups of people, who all need varying access? In this tutorial we’ll go over the basics of ACLs and employ them in a fictional office scenario.
What Are ACLs?
Access Control Lists (ACLs) supplement thestandard file system permissions model on Linux and Unix. In a nutshell, they allow you to go beyond the “user/group/other” concept to create additional sets of permissions for files and directories. They also do neat things like automatically applying permissions to new files and directories. But first, let’s cover some basic Linux file system permissions concepts in which ACLs work alongside.
Standard File System Permissions
To understand file system permissions under Linux, first you need to know that Linux is a “multi-user operating system”. This means there exist multipleuser accountswhich essentially allow more than one person to log into the system, each having their own freedoms and restrictions.
Some user accounts are “system” accounts; not ones that are used by a person, but rather by a piece of software, for instance. Processes run under these special accounts to allow and restrict them to various parts of the OS, just as a normal user account would.
Now that we understand users, I can introduce you to “groups.” Groups are pretty easy to understand—they’re simply collections of existing users. To assign permission for a resource to lots of users at the same time, you can create a new group and grant specific users membership to that group. You then assign permission for the resource to the group, instead of each individual user. This makes administration easier and more streamlined.
OK, let’s talk about files and directories. These are the resources we care about granting and protecting access to.
Most Linux file systems (EXT4, XFS and ZFS for example) allow you to apply 3 primary permissions to files and directories. These permissions are:
All files and directories on a file system have standard permission assigned to 3 distinct entities: the user who owns it, the group owner and all other users. Each entity may have a combination of read, write and execute (r/w/x) permissions assigned. You canuse the ls commandto look at all of this info:
By default, each newly created user is also assigned to a new primary group of the same name. In the example above, #4 is the username “user” and #5 is the group name “user”. Keep that in mind when looking at output such as this as it may be confusing at first.
The files and directories that users are allowed to modify depend on a couple of things, including whether the user “owns” it or if they otherwise have the appropriate permissions to via a group membership. Note that theroot usercan modify any file on the system, regardless of ownership.
This approach to file system permissions works well for most at-home and standalone setups. Of course, when you’re working with systems where multiple users are accessing the same file hierarchy, and you must give certain people access to some areas (and restrict them from others), you’ll start to understand the standard “1 owner, 1 group” methodology falls a bit short.
How ACLs Enhance the Standard Permissions Model
Access Control Lists add the ability to apply permission entries to multiple users and groups for files and directories. One example where ACLs are a good option is when you want to assign a certain user permission to a file that already has specific owner and group owner permissions assigned.
ACLs for directories follow the standard permissionsr/w/xmodel in that they give you the ability to (r)ead (list contents, but not enter) the directory, (w)rite (create) new files and directoriesinsidethe directory, and e(x)ecute (enter) the directory.
How about an example? Let’s say you have a file, report.pdf, owned by a user, peter, with read+write permissions. You’ve additionally granted group ownership of this file to the accounting group. Now you’ve received a request to grant read access to the user named lumberg.
Let’s assume you’re using the standard permissions model. Here are a few (futile) ideas for completing this request:
What to do? Well, youcouldjust take an early lunch break. However, let’s instead employ ACLs!
Checking for ACL Support on Your System
Most modern Linux distributions support ACLs out-of-the-box. Most common file systems support them, their default mount options include ACL support and default installations should include the proper packages.
To verify on ext2/3/4 file systems, use tune2fs. For example, if you want to check /dev/sda1 (which contains an ext4 file system):
For reference, here’s alist of different file system support for ACLs, grouped by platform, written by IBM.
The getfacl Command
The getfacl command displays (gets) file access control lists for files and directories. If you run getfacl on our report file from above, you’ll see:
Right now the output shows theminimum ACLof the file. The minimum ACL comprises the standard permissions for the owner, owning group and all other users.
If there were anextended ACLentry for another user, let’s call them michael, we’d see this:
In addition to the minimum ACLs, we now have an extended ACL entry for user michael (read+write permissions). If you list the file again with extended ACLs, you’ll notice a plus (+) sign to the right of the “other users” permissions, indicating that extended ACL entries exist:
The setfacl Command
The setfacl command is what actuallysetsACLs for files and directories. It adds and removes user and group entries, modifies permissions and other tasks like setting default ACLs on directories and working with masks. We’ll use it to complete the request above by granting the lumberg user read access to report.pdf.
To add the new user ACL entry, you’ll use setfacl with this syntax (which I’ll break down below):
Now that this is set we can take a look, using getfacl, once again:
Do you spot our new entry?
Default ACLs
Default ACLs only apply to directories (folders). When you set a default ACL on a directory, the entry you specify will automatically be applied toeverynew file and directory within it, regardless of who creates them. It’s sort of a catch-all, recursive approach which makes it pretty useful when you’re planning your file system hierarchy.
Let’s ensure Lumberg will be able to read new files and enter new directories that are created under Accounting. We’ll use the -d option for adding adefault ACL:
An upper-caseXapplies the execute permission only against new subdirectories; not files.
Access control lists are great for when you want to take your file system permissions to the next level. You can get away with a lot with standard user/group/other permissions, but there will likely be a point in your journeys where using ACLs makes much more sense.
