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 calendar.cal
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 calendar.cal # file: calendar.cal # owner: alice # group: ateam user::rw- group::r-- other::r--
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.
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- calendar.cal
The parameters only appear cryptic at first glance: the above command line creates a new entry (-m) in the ACL for the calendar.cal 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 calendar.cal # file: calendar.cal # owner: alice # group: ateam user::rw- user:bob:rw- group::r-- mask::rw-- other::r--
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 has the following useful parameters: -m modifies or creates a new entry,
setfacl -m user:bob:r-- calendar.cal
which is deleted by -x:
setfacl -x user:bob calendar.cal
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-- calendar.cal
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- calendar.cal
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- calendar.cal
Buy this article as PDF
Weird data transfer technique avoids all standard security measures.
FIDO alliance declares the beginning of the end for old-style login authentication.
Legendary Uber-distro splits over the systemd controversy.
One of CeBIT’s most successful forums returns in 2015.
A new study says it is possible to unmask 81% of TOR users.
Redmond joins the revolution by turning the .NET Core Runtime into a GitHub project.
Users only had 7 hours to update before the intrusions started.
It's official: The new web arrives