Manage POSIX Access Control Lists (ACLs)

Use ACLs

• To use ACLs, you need to be familiar with:

How ACLs Work

• ACLs provide an extension of the three traditional sets of permissions:

• Applied to:

• ACLs allow you to assign permissions to individual users or groups even if they are not the owner or a member of the owning group.

Access Control Lists provide an extension of the traditional file permission concept. They allow you to assign permissions to individual users or groups even if these do not correspond to the original owner or the owning group.

ACLs are a feature of the Linux kernel and are supported by the Ext2/3/4, XFS, and BtrFS file systems (and others, but those listed are most relevant for SLE12). Using ACLs, you can create complex scenarios without implementing complex permission models on the application level. The advantages of ACLs are clearly evident in situations like replacing a Windows server with a Linux server providing file and print services with Samba. Since Samba supports ACLs, user permissions can be configured both on the Linux server and in Windows.

• ACL Example:

Attach:acl1.png

Allowing write access to a file to one single user besides the owning user is a simple scenario where ACLs come in handy. Using the conventional approach, you would have to create a new group, make the two users involved members of the group, change the owning group of the file to the new group, and then grant write access to the file for the group. root access would be required to create the group and to make the two users members of that group. With ACLs, you can achieve the same results by making the file writable for the owner plus the named user, as shown above.

Another advantage of this approach is that the system administrator does not have to get involved to create a group. The user can decide on his own whom he grants access to his files. Note that the output of ls changes when ACLs are used (see the second output of ls above). A + is added to alert to the fact that ACLs are defined for this file, and the permissions displayed for the group have a different significance. They display the value of the ACL mask now, and no longer the permissions granted to the owning group.

ACL Types

• Two basic classes of ACLs:

• ACLs extend the classic Linux file permissions:

These named group and named user entries are assigned to the group class, which already contains the owning group entry.

• All possible ACL types:

Attach:acl3.png

Different from the POSIX.1 permission model, the group class may now contain ACL entries with different permission sets, so the group class permissions alone are no longer sufficient to represent all the detailed permissions of all ACL entries it contains. Therefore, the meaning of the group class permissions is redefined: under their new semantics, they represent an upper bound of the permissions that any entry in the group class will grant.

This upper bound property ensures that POSIX.1 applications that are unaware of ACLs will not suddenly and unexpectedly start to grant additional permissions once ACLs are supported.

In minimal ACLs, the group class permissions are identical to the owning group permissions. In extended ACLs, the group class may contain entries for additional users or groups. This results in a problem: some of these additional entries may contain permissions that are not contained in the owning group entry, so the owning group entry permissions may differ from the group class permissions.

This problem is solved by the virtue of the mask entry. With minimal ACLs, the group class permissions map to the owning group entry permissions. With extended ACLs, the group class permissions map to the mask entry permissions, whereas the owning group entry still defines the owning group permissions.

ACL Terminology

Important ACL terms include:

• User classes: The conventional POSIX permission concept uses three classes of users for assigning permissions in the file system: the owning user, the owning group, and other users. Three permission bits can be set for each user class, giving permission to read (r), write (w), and execute (x).

• Access ACL: Determine access permissions for users and groups for all kinds of file system objects (files and directories).
• Default ACL: Can be applied only to directories. They determine the permissions a file system object inherits from its parent directory when it is created.
• ACL entry: Each ACL consists of a set of ACL entries. An ACL entry contains a type, a qualifier for the user or group the entry refers to, and a set of permissions. For some entry types, the qualifier for the group or users is undefined.

ACLs and Permission Bits

• The following graphic shows the mapping of minimal ACLs:

Attach:acl2.png

Effective Permissions

• In the following example, effective permissions for the user jane are shown:

Attach:acl4.png

The permissions defined in the entries owner and other are always effective. Except for the mask entry, all other entries (named user, owning group, and named group) can be either effective or masked. If permissions exist in the named user, owning group, or named group entries as well as in the mask, they are effective (logical AND). Permissions contained only in the mask or only in the actual entry are not effective.

The ACL contains two entries, one for the named user jane and one mask entry. Jane has permissions to read and execute the corresponding file, but the mask only contains permissions for reading and writing. Because of the AND combination, the effective rights allow jane to only read the file.

Extended ACL

• Following is an example of extended ACLs:

Attach:acl5.png

In both cases (minimal and extended ACL), the owner class permissions are mapped to the ACL entry owner. Other class permissions are mapped to their respective ACL entry. However, the mapping of the group class permissions is different in the second case. In the case of minimal ACLs without a mask, the group class permissions are mapped to the ACL entry owning group. In the case of extended ACLs with a mask, the group class permissions are mapped to the mask entry. This mapping approach ensures the smooth interaction of applications, regardless of whether they have ACL support or not.

The access permissions that were assigned by permission bits (for instance with the chmod command) represent the upper limit for all other adjustments made by ACLs. Any permissions not reflected here are either not in the ACL or are not effective. Changes made to the permission bits are reflected by the ACL and vice versa.

Set ACLs with setfacl

• setfacl options:

Display ACLs with getfacl

• getfacl options:

Define Extended ACLs: Examples

• Named user:

• Named groups:

• Mask:

The number of possible ACL entries depends on the file system, ext2/3 supports 32 entries, XFS 25.

When setting the mask, one colon works as well:

Configure Directory Access ACLs (1/7)

• Use the umask command to define which access permissions should be masked.

Attach:acl6.png

• Check the initial state of the ACL by entering:

Attach:acl7.png

The output of getfacl precisely reflects the mapping of permission bits and ACL entries as described before. The first three output lines display the name, owner, and owning group of the directory. The next three lines contain the three ACLs. In fact, in the case of this minimum ACL, the getfacl command does not produce any information you could not have obtained with ls.

• Modify the ACL as follows:

• Use the getfacl command display the resulting ACL:

Attach:acl8.png

Your first modification of the ACL is the assignment of read, write, and execute permissions to an additional user jane and an additional group jungle. The m option prompts setfacl to modify the existing ACL. The following argument indicates the ACL entries to modify (several entries are separated by commas). The final part specifies the name of the directory these modifications should be applied to.

Use the getfacl command to view the resulting ACL. In addition to the entries initiated for the user jane and the group jungle, a mask entry has been generated. This mask entry is set automatically to reduce all entries in the group class to a common denominator. In addition, setfacl automatically adapts existing mask entries to the settings you modified, provided you do not deactivate this feature with -n.

The mask type defines the maximum effective access permissions for all entries in the group class. This includes named user, named group, and owning group.

• The group class permission bits ls -dl mydir now displays correspond to the mask entry:

Attach:acl9.png

The first column of the output now contains an additional + to indicate that there is an extended ACL for this item.

According to the output of the ls command, the permissions for the mask entry include write access. Traditionally, such permission bits would mean that the owning group (in this example project3) also has write access to the mydir directory.

However, the effective access permissions for the owning group correspond to the overlapping portion of the permissions defined for the owning group and for the mask, which is r-x in the example. As far as the effective permissions of the owning group are concerned, nothing has changed even after adding the ACL entries.

• In the following example, the write permission for the owning group is removed with the chmod command.

Attach:acl10.png

After executing the chmod command to remove the write permission from the group class bits, the output of the ls command is sufficient to see that the mask bits have changed accordingly: write permission is again limited to the owner of mydir.

The output of the getfacl confirms this. This output includes a comment for all those entries in which the effective permission bits do not correspond to the original permissions because they are filtered according to the mask entry.

• The original permissions can be restored at any time with chmod:

Attach:acl11.png

• You can also change the mask with setfacl using:

Attach:acl12.png

If you want to change the permissions specifically for the owning group on a file or directory that has extended ACLs defined, you need to do that with setfacl, as chmod would only change the mask:

Configure a Directory with Default ACLs

• Default ACLs for a directory define the access permissions objects in the directory inherit when they are created:

Directories can have a default ACL, which is a special kind of ACL that defines the access permissions that objects under the directory inherit when they are created. A default ACL affects subdirectories as well as files. There are two different ways in which the permissions of a directory's default ACL are passed to the files and subdirectories in it:

A subdirectory inherits the default ACL of the parent directory both as its own default ACL and as its own access ACL.

A file inherits the default ACL as its own access ACL.

All system functions that create file system objects use a mode parameter that defines the access permissions for the newly created file system object. If the parent directory does not have a default ACL, the permission bits are set depending on the setting of umask. If a default ACL exists for the parent directory, the permission bits assigned to the new object correspond to the overlapping portion of the permissions of the mode parameter and those that are defined in the default ACL. The umask command is disregarded in this case.

Directory Default ACL Example

• Add default ACLs to the existing mydir directory:

Attach:acl13.png

getfacl returns both the access ACL and the default ACL. The default ACL is formed by all lines that start with default.

Although you merely executed the setfacl command with an entry for the jungle group for the default ACL,

setfacl automatically copied all other entries from the access ACL to create a valid default ACL. Default ACLs do not have an immediate effect on access permissions. They come into play only when file system objects are created. These new objects inherit permissions only from the default ACL of their parent directory.

• mkdir is used to create a subdirectory, which inherits the default ACL:

Attach:acl14.png

As expected, the newly created mysubdir subdirectory has permissions from the default ACL of the parent directory. The access ACL of mysubdir is an exact reflection of the default ACL of mydir, as is the default ACL that this directory hands down to its subordinate objects.

• In the following example, touch is used to create a file in the mydir directory:

Attach:acl15.png

touch passes a mode with the value 0666, which means that new files are created with read and write permissions for all user classes, provided no other restrictions exist in umask or in the default ACL. In effect, this means that all access permissions not contained in the mode value are removed from the respective ACL entries. Although no permissions were removed from the ACL entry of the group class, the mask entry was modified to mask permissions not set using mode.

This approach ensures the smooth interaction of applications, such as compilers, with ACLs. You can create files with restricted access permissions and subsequently assign them as executable. The mask mechanism guarantees that the right users and groups can execute them as desired.

Additional setfacl Options

• Use -x to delete named user entries.

• Use -b to remove all ACL entries.
• Use -M to restore ACLs that have been written to a file.

Attach:acl16.png Δ

ACL Check Algorithm

• A check algorithm is applied before access is granted to an ACL-protected file system object.

• The sequence for reviewing ACL entries is:

The access check algorithm can be described in pseudo-code as follows.

the user ID of the process is the owner, the owner entry determines access

the user ID of the process matches the qualifier in one of the named user entries, this entry determines access

one of the group IDs of the process matches the owning group and the owning group entry contains the requested permissions, this entry determines access

one of the group IDs of the process matches the qualifier of one of the named group entries and this entry contains the requested permissions, this entry determines access

one of the group IDs of the process matches the owning group or any of the named group entries, but neither the owning group entry nor any of the matching named group entries contains the requested permissions, this determines that access is denied

the other entry determines access.

the matching entry resulting from this selection is the owner or other entry and it contains the requested permissions, access is granted

the matching entry is a named user, owning group, or named group entry and this entry contains the requested permissions and the mask entry also contains the requested permissions (or there is no mask entry), access is granted

access is denied.

Some of the information in this objective on ACLs was taken from http://users.suse.com/~agruen/acl/linuxacls/online/ were you can find detailed information on ACLs on Linux.

How Applications Handle ACLs

• udev uses ACLs to allow users logged in to the graphical user interface to access devices, such as DVD drives
• Some applications lack ACL support: