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-- calendar.cal
$ getfacl calendar.cal
# file: calendar.cal
# owner: alice
# group: ateam
user::rw-
user:bob:rw-
group::r--
group:bteam:r--
mask::rw--
other::r--

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.

Legacy

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

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

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- calendar.cal

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 calendar.cal

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-- calendar.cal

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 calendar.cal
# file: calendar.cal
# owner: alice
# group: ateam
user::rw-
user:bob:rw-    #effective:r--
group::r--
mask::r--
other::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.

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

Standard

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).

$ setfacl -m user:bob:rw- projectfolder
$ setfacl -d --set user:bob:rw- projectfolder
$ getfacl projectfolder
# file: projectfolder
# owner: alice
# group: ateam
user::rwx
user:bob:rw-
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:bob:rw-
default:mask::rwx
default:other::r-x

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.

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