This section explains the basic structure of an ACL and its various characteristics. The interrelation between ACLs and the traditional permission concept in the Linux file system is briefly demonstrated by means of several figures. Two examples show how to create your own ACLs using the correct syntax. In conclusion, find information about the way ACLs are interpreted by the operating system.
There are two basic classes of ACLs: A minimum ACL merely comprises the entries for the types owner, owning group, and other, which correspond to the conventional permission bits for files and directories. An extended ACL goes beyond this. It must contain a mask entry and may contain several entries of the named user and named group types. Table B.1. “ACL Entry Types” provides a summary of the various types of ACL entries that are possible.
Table B.1. ACL Entry Types
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 one of the above-mentioned entries as well as in the mask, they are effective. Permissions contained only in the mask or only in the actual entry are not effective. The example in Table B.2. “Masking Access Permissions” demonstrates this mechanism.
Figure B.1. “Minimum ACL: ACL Entries Compared to Permission Bits” and Figure B.2. “Extended ACL: ACL Entries Compared to Permission Bits” illustrate the two cases of a minimum ACL and an extended ACL. The figures are structured in three blocks — the left block shows the type specifications of the ACL entries, the center block displays an example ACL, and the right block shows the respective permission bits according to the conventional permission concept as displayed by ls -l, for instance. In both cases, the owner class permissions are mapped to the ACL entry owner. Equally, other class permissions are mapped to the respective ACL entry. However, the mapping of the group class permissions is different in the two cases.
In the case of a minimum ACL — without mask — the group class permissions are mapped to the ACL entry owning group. This is shown in Figure B.1. “Minimum ACL: ACL Entries Compared to Permission Bits”.
In the case of an extended ACL — with mask — the group class permissions are mapped to the mask entry. This is shown in Figure B.2. “Extended ACL: ACL Entries Compared to Permission Bits”.
This mapping approach ensures the smooth interaction of applications, regardless of whether they have ACL support. The access permissions that were assigned by means of the permission bits represent the upper limit for all other “fine adjustments” made by means of ACLs. Any permissions not reflected here were either not set in the ACL or are not effective. Changes made to the permission bits are reflected by the ACL and vice versa.
The handling of access ACLs is demonstrated in three steps by means of the following example:
Creating a file system object (a directory in this case)
Modifying the ACL
Before you create the directory, use the umask command to define which access permissions should be masked each time a file object is created. The command umask 027 sets the default permissions by giving the owner the full range of permissions (0), denying the group write access (2), and giving other users no permissions at all (7). umask actually masks the corresponding permission bits or turns them off. For details, consult the corresponding man page (man umask).
mkdir mydir should create the mydir directory with the default permissions as set by umask. Use the following command to check if all permissions were assigned correctly:
ls -dl mydir drwxr-x--- ... tux project3 ... mydir
Check the initial state of the ACL and insert a new user entry and a new group entry with getfacl mydir. This gives information like:
# file: mydir # owner: tux # group: project3 user::rwx group::r-x other::---
The output of getfacl precisely reflects the mapping of permission bits and ACL entries as described in Section B.3.2. “ACL Entries and File Mode Permission Bits”. The first three output lines display the name, owner, and owning group of the directory. The next three lines contain the three ACL entries owner, owning group, and other. In fact, in the case of this minimum ACL, the getfacl command does not produce any information you could not have obtained with ls.
Your first modification of the ACL is the assignment of read, write, and execute permissions to an additional user jane and an additional group djungle.
setfacl -m user:jane:rwx,group:djungle:rwx mydir
The option -m 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 to which these modifications should be applied. Use the getfacl command to take a look at the resulting ACL.
# file: mydir # owner: tux # group: project3 user::rwx user:jane:rwx group::r-x group:djungle:rwx mask::rwx other::---
In addition to the entries initiated for the user jane and the group djungle, a mask entry has been generated. This mask entry is set automatically to reduce all entries in the group class to a common denominator. Furthermore, setfacl automatically adapts existing mask entries to the settings modified, provided you do not deactivate this feature with -n. mask 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 that would be displayed by ls -dl mydir now correspond to the mask entry.
drwxrwx---+ ... tux project3 ... mydir
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 (here project3) also has write access to the directory mydir. 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 our example (see Table B.2. “Masking Access Permissions”). As far as the effective permissions of the owning group are concerned, nothing has changed even after the addition of the ACL entries.
Edit the mask entry with setfacl or chmod.
chmod g-w mydir ls -dl mydir drwxr-x---+ ... tux project3 ... mydir
getfacl mydir # file: mydir # owner: tux # group: project3 user::rwx user:jane:rwx # effective: r-x group::r-x group:djungle:rwx # effective: r-x mask::r-x other::---
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 must 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:
chmod g+w mydir ls -dl mydir drwxrwx---+ ... tux project3 ... mydir
getfacl mydir # file: mydir # owner: tux # group: project3 user::rwx user:jane:rwx group::r-x group:djungle:rwx mask::rwx other::---
Directories can have a default ACL, which is a special kind of ACL defining 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 an access ACL.
A file inherits the default ACL as its own access ACL.
All system calls 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 as defined by the umask are subtracted from the permissions as passed by the mode parameter, with the result being assigned to the new object.
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 is disregarded in this case.
The following three examples show the main operations for directories and default ACLs:
Creating a default ACL for an existing directory
Creating a subdirectory in a directory with default ACL
Creating a file in a directory with default ACL
Add a default ACL to the existing directory mydir with:
setfacl -d -m group:djungle:r-x mydir
The option -d of the setfacl command prompts setfacl to perform the following modifications (option -m) in the default ACL.
Take a closer look at the result of this command:
getfacl mydir # file: mydir # owner: tux # group: project3 user::rwx user:jane:rwx group::r-x group:djungle:rwx mask::rwx other::--- default:user::rwx default:group::r-x default:group:djungle:r-x default:mask::r-x default:other::---
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 djungle 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 only come into play when file system objects are created. These new objects inherit permissions only from the default ACL of their parent directory.
In the next example, use mkdir to create a subdirectory in mydir, which will “inherit” the default ACL.
mkdir mydir/mysubdir getfacl mydir/mysubdir # file: mydir/mysubdir # owner: tux # group: project3 user::rwx group::r-x group:djungle:r-x mask::r-x other::--- default:user::rwx default:group::r-x default:group:djungle:r-x default:mask::r-x default:other::---
As expected, the newly-created subdirectory mysubdir has the permissions from the default ACL of the parent directory. The access ACL of mysubdir is an exact reflection of the default ACL of mydir, just as the default ACL that this directory will hand down to its subordinate objects.
Use touch to create a file in the mydir directory:
touch mydir/myfile ls -l mydir/myfile -rw-r-----+ ... tux project3 ... mydir/myfile
getfacl mydir/myfile # file: mydir/myfile # owner: tux # group: project3 user::rw- group::r-x # effective:r-- group:djungle:r-x # effective:r-- mask::r-- other::---
Important in this example: touch passes on 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 (see Section B.3.4.1. “Effects of a 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 via mode.
This approach ensures the smooth interaction of applications, such as compilers, with ACLs. You can create files with restricted access permissions and subsequently mark them as executable. The mask mechanism guarantees that the right users and groups can execute them as desired.
A check algorithm is applied to all processes or applications before they are granted access to an ACL-protected file system object. As a basic rule, the ACL entries are examined in the following sequence: owner, named user, owning group or named group, and other. The access is handled in accordance with the entry that best suits the process. Permissions do not accumulate.
Things are more complicated if a process belongs to more than one group and would potentially suit several group entries. An entry is randomly selected from the suitable entries with the required permissions. It is irrelevant which of the entries triggers the final result “access granted”. Likewise, if none of the suitable group entries contains the correct permissions, a randomly selected entry triggers the final result “access denied”.