Working with Access Control Lists

Who Has Rights?

In the course of the project, Alice needs to grant the other members of Bob's group short-term access to her calendar. To do so, she simply adds an entry for bteam:

setfacl -m group:bteam:r--
$ getfacl
# file:
# owner: alice
# group: ateam

When read access for a file is requested, Linux simply checks permissions one after another.

First, the kernel checks to see whether the user has an entry, and if so, Linux applies the permissions defined by the entry. In the example here, Bob is granted read and write access to the calendar. In contrast, a personal entry does not exist for Carl, so Linux checks group permissions. Because Carl is a member of bteam, he is given read access. The kernel is unable to find a personal or group entry for the staff from accounts; in this case, standard Unix permissions apply.


Unfortunately, ls -l does not display extended permissions. Instead, a single plus sign indicates the existence of extended permissions:

$ ls -l
-rw-r--r--+ 1 alice ateam 5410 7. Feb 11:21

Because the ACLs map standard Unix permissions, setfacl also replaces the good old chmod command. You simply have to change the entries. For example, the command

setfacl -m other::rw-

grants read and write access for the file to all other users, including accounts:

-rw-r--rw-+ 1 alice ateam 5410 7. Feb 11:21

Every extended ACL contains a fairly ominous looking mask entry. The mask describes the maximum permissions the user can be granted.

If the mask defines a more restrictive permission set than is granted to a user in an ACE, the mask always takes priority. For example, Alice could have granted other members of Bob's group access to her calendar.

If she now wants to temporarily revoke these permissions, she would have to modify them for each member of the group; alternatively, she can just modify the mask:

setfacl -m mask::r--

No matter what permissions the users have beforehand, from now on, they can only read the calendar. Of course, this applies to Bob too. Although he still has write permissions for the calendar, the mask takes priority, leaving him with just three permissions.

Under the hood, Linux performs a logical AND operation to calculate effective rights. To be able to read a file, the user or group thus needs read permissions and read permissions must exist in the mask.

To avoid administrators losing track, getfacl outputs the effective actual permissions for each user:

$ getfacl
# file:
# owner: alice
# group: ateam
user:bob:rw-    #effective:r--

Although Bob has write permissions, all he effectively keeps is read permission for the calendar.

Masks introduce another pitfall: setfacl autonomously changes the mask whenever you modify the permissions for user or group. If you misuse the mask, like Alice did in the example here, you have no alternative but to check its validity.


To create complex ACLs, you need to run setfacl multiple times, which is unwieldy and time consuming. Luckily, administrators can store the entries in a text file in the same format as getfacl output and then run setfacl with the --set-file="file.txt" parameter to restore the permissions. The use of - instead of a file name tells the tool to read the parameters from standard input. This means that you can move an ACL from one file to another:

getfacl file1 | setfacl --set-file=- file2


While she is working on a project, Alice creates a number of project files that Bob also needs to read. For each new document, Alice could theoretically modify the permissions manually. An easier option is to create directories with a default ACL. The subdirectories and files below the directory automatically inherit the default permissions. Directories have both an ACL of their own and the new default ACL of the parent directory. You can create a new default ACL by running setfacl (see Listing 1).

Listing 1

Creating a Default ACL

$ setfacl -m user:bob:rw- projectfolder
$ setfacl -d --set user:bob:rw- projectfolder
$ getfacl projectfolder
# file: projectfolder
# owner: alice
# group: ateam

getfacl always lists standard permissions at the end. The format reflects the legacy entries, but each time starts with default. If you are only interested in the default entries, you can specify getfacl -d; alternatively, getfacl -a prevents the default entries from being displayed.

Because file access is handled through the kernel itself, legacy programs have no trouble working with extended permissions, which is not true of applications that manipulate file permissions, such as Konqueror or Nautilus. Konqueror version 3.5 or later can handle ACLs (as you can see in Figure 1), as can Nautilus 2.16 or newer.

Figure 1: In KDE's Konqueror, the Extended permissions button in the File Properties dialog box takes you to this dialog, where you can conveniently modify ACL entries.

Standard Unix commands such as cp or mv have been modified to handle ACLs. Loss-free copying or moving assumes that the target file system supports ACLs. If not, you only keep simple, legacy file permissions.

Programs that have not been modified to support ACLs simply change the standard permissions. One example of this is performing the backup. The legacy tar program does not keep ACLs. In this case, you should choose an alternative, such as Star tape archiver (star), which is included with many distributions. The command

star H=pax -acl -c -f backup.pax project_folder/

creates (-c) the archive (-f) backup.pax and stores the contents of the project_folder in it. The program uses the PAX file format. The command

star -acl -xp -acl -f backup.pax

unpacks the package created by the previous command.

If you prefer to avoid exotic formats, I recommend a simple trick: You can tell setfacl to parse its parameters from a text file. The format precisely matches the output from getfacl, so it would seem to make sense to use getfacl to store all of the ACLs in a text file and then run setfacl later to restore them. To start, write the ACL output from getfacl to a text file:

getfacl -R --skip-base directory/ > /backup.acl

This tells getfacl to change to directory and write the ACLs for all the objects it finds to a file called backup.acl. The -R parameter makes this process recursive. Then, you can store the ACL file with the actual content of the directory using your preferred packer. To restore the ACLs, run setfacl:

setfacl --restore=backup.acl

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Alice 3.1

    If you can use your desktop environment, then you can also write programs: All you need is your mouse, the Alice IDE, and some time to experiment.

  • Command Line: Access Control

    A sophisticated system of users and permissions precisely controls who has access to what on Linux. At the command line, you can define ownership with the chmod, chgrp, and chown tools.

  • Security Lessons: Virtual Hosts

    Creating secure websites with their own privileges on a single server.

  • Samba 4

    Since the release of the final version, Samba 4 has become increasingly significant in IT practice; now it has found its way into Jessie, the next Debian release. We take a look at the new features.

  • Mozilla Lightning

    The Lightning add-on lets users upgrade their Mozilla Thunderbird email client and turn it into a convenient, versatile groupware product.

comments powered by Disqus

Direct Download

Read full article as PDF:

032-035_acls.pdf  (240.38 kB)


njobs Europe
Njobs Netherlands Njobs Deutschland Njobs United Kingdom Njobs Italia Njobs France Njobs Espana Njobs Poland
Njobs Austria Njobs Denmark Njobs Belgium Njobs Czech Republic Njobs Mexico Njobs India Njobs Colombia