Working with Access Control Lists


To begin this study of ACLs, I'll take a quick look at the legacy Linux access control system. Normally in Linux, each filesystem object distinguishes between three different roles, which are called classes in POSIX terminology: the owner of the file (user), the group the file belongs to (group), and all other users (other). The owner specifies – for each of the three classes – whether the class can read, write to, or even execute the file. The familiar ls -l command displays these permissions as a cryptic list of letters:

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

In this case, alice is the owner and her group is called ateam. ls appreciates read, write, and execute commissions to their first letters: rread, write, and execute. Thus, for each class of users, a triplet of access permissions is used in rwx format. A dash (-) at any position means that the operation is forbidden.


Imagine an ACL as a piece of paper on which you jot a list of all other access permissions and the rights assigned to them. Linux staples the results onto the file and enforces the permissions on the list. In practice, Alice first checks which permissions are already assigned for her calendar. She uses getfacl to do so; the command outputs the ACL for a file. Because she has not yet added Bob, his list should be empty:

$ getfacl
# file:
# owner: alice
# group: ateam

For a list that should really be empty, this has quite a few entries.

First, getfacl repeats the file name, the owner of the file, and the group in the first three lines. The following lines each contain exactly one entry from the ACL; this is aptly known as an Access Control Entry (ACE). To retain downward compatibility with legacy systems, the ACL automatically maps existing permissions to entries in the list – this explains the three following lines in the above example. The first line shows the owner's permissions, the second shows permissions for the group, and the third shows those for all other users.

The entries thus precisely match what ls -l told us. Because these entries exist in any ACL, they are referred to as the minimal ACL. As soon as an entry is added, this is referred to as an extended ACL.

Windows and ACLs

Windows, as of XP, and the NT operating system family also support ACLs, but only with the NTFS filesystem. Although access to NTFS on Linux is typically possible, Linux has only limited support for its extended functionality, which unfortunately includes ACLs.

At least Samba supports ACLs, assuming the underlying system has support for extended permissions. Files stored on the Samba server keep their permissions as if they were stored on a normal NTFS drive. One problem remains: Because the ACLs use by Windows and Linux differ, Samba currently gives Windows users only a part of the functionality they are used to.

Setting ACEs

To grant Bob access to the calendar, Alice needs to set another entry for this ACL. The setfacl tool takes care of this:

setfacl -m user:bob:rw-

The parameters only appear cryptic at first glance: the above command line creates a new entry (-m) in the ACL for the file. Access is granted to a single user called bob. Bob can read and write to the file, but he can't execute it (rw-). getfacl outputs the resulting list:

$ getfacl
# file:
# owner: alice
# group: ateam

Each entry in an ACL follows the same pattern, starting with the type, which specifies to whom the following permissions were applied. This can be a single user or a whole group. A label follows the colon. This designates the name of the user or group the entry belongs to. In cases in which you do not need this name, you can simply omit it – you can see an example of this in the entries for standard permissions. The line ends with the familiar triplet of permissions.

Setfacl Investigated

setfacl has the following useful parameters: -m modifies or creates a new entry,

setfacl -m user:bob:r--

which is deleted by -x:

setfacl -x user:bob

This only removes the specified entry, but it does not affect the group that Bob belongs to. --set removes all previous entries, setting only the new ones:

setfacl --set user:bob:r--

Finally, the -b option empties the complete list. Additionally, setting the recursive parameter -R tells setfacl to work its way through the whole directory tree. At the same time, you can even set multiple comma-separated permissions:

setfacl -m user:bob:r--, group:cteam:rw-

Instead of user and group names, you can alternatively specify the UIDs and GIDs; setfacl will also accept permissions in a numeric format.

A couple of abbreviations apply in setfacl. Instead of user, you can simply say u. In similar fashion, the abbreviations g(roup), m(ask), o(ther) and d(efault) exist. It is also possible to leave out multiple subsequent dashes, as long as the command is unambiguous:

setfacl -m u:bob:r-

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)