Table 35.1, “ACL Entry Types” summarizes the six possible types of ACL entries, each defining permissions for a user or a group of users. The owner entry defines the permissions of the user owning the file or directory. The owning group entry defines the permissions of the file's owning group. The superuser can change the owner or owning group with chown or chgrp, in which case the owner and owning group entries refer to the new owner and owning group. Each named user entry defines the permissions of the user specified in the entry's qualifier field, which is the middle field in the text form shown in Table 35.1, “ACL Entry Types”. Each named group entry defines the permissions of the group specified in the entry's qualifier field. Only the named user and named group entries have a qualifier field that is not empty. The other entry defines the permissions of all other users.
The mask entry further limits the permissions granted by named user, named group, and owning group entries by defining which of the permissions in those entries are effective and which are masked. If permissions exist in one of the 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—meaning the permissions are not granted. All permissions defined in the owner and owning group entries are always effective. The example in Table 35.2, “Masking Access Permissions” demonstrates this mechanism.
There are two basic classes of ACLs: A minimum ACL contains only 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 35.1. ACL Entry Types
Type | Text Form |
---|---|
owner |
|
named user |
|
owning group |
|
named group |
|
mask |
|
other |
|
Table 35.2. Masking Access Permissions
Entry Type | Text Form | Permissions |
---|---|---|
named user |
|
|
mask |
|
|
effective permissions: |
|
Figure 35.1, “Minimum ACL: ACL Entries Compared to Permission Bits” and
Figure 35.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, for example, as displayed by ls
-l
. In both cases, the owner
class permissions are mapped to the ACL entry
owner. 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 35.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 35.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 with an ACL. Changes made to the permission bits are reflected by the ACL and vice versa.
The handling of access ACLs is demonstrated in the following example:
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
ls -dl mydir
to check if all
permissions were assigned correctly. The output for this example is:
drwxr-x--- ... tux project3 ... mydir
With getfacl mydir
, check the
initial state of the ACL. 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 35.3.1, “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.
Modify the ACL to assign read, write,
and execute permissions to an additional user geeko
and
an additional group mascots
with:
setfacl -m user:geeko:rwx,group:mascots:rwx mydir
The option -m
prompts
setfacl to modify the existing ACL. The following
argument indicates the ACL entries to modify (multiple 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:geeko:rwx group::r-x group:mascots:rwx mask::rwx other::---
In addition to the entries initiated for the user
geeko
and the group mascots
, a
mask entry has been generated. This
mask entry is set automatically so that all
permissions are effective.
setfacl automatically adapts existing
mask entries to the settings modified, unless you
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 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 35.2, “Masking Access Permissions”). As far
as the effective permissions of the owning
group in this example are
concerned, nothing has changed even after the addition of the ACL
entries.
Edit the mask entry with
setfacl or chmod.
For example, use chmod g-w
mydir
. ls -dl
mydir
then shows:
drwxr-x---+ ... tux project3 ... mydir
getfacl mydir
provides the
following output:
# file: mydir # owner: tux # group: project3 user::rwx user:geeko:rwx # effective: r-x group::r-x group:mascots: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 g+w mydir
.
Directories can have a default ACL, which is a special kind of ACL defining the access permissions that objects in the directory inherit when they are created. A default ACL affects both subdirectories and 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 default ACL and as an access ACL.
A file inherits the default ACL as its 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:
Add a default ACL to the existing directory
mydir
with:
setfacl -d -m group:mascots: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:geeko:rwx group::r-x group:mascots:rwx mask::rwx other::--- default:user::rwx default:group::r-x default:group:mascots: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
mascots
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
inherits the default ACL.
mkdir mydir/mysubdir getfacl mydir/mysubdir # file: mydir/mysubdir # owner: tux # group: project3 user::rwx group::r-x group:mascots:r-x mask::r-x other::--- default:user::rwx default:group::r-x default:group:mascots: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
. The
default ACL that this directory will hand down to its subordinate
objects is also the same.
Use touch to create a file in the
mydir
directory, for example,
touch mydir/myfile
.
ls -l mydir/myfile
then
shows:
-rw-r-----+ ... tux project3 ... mydir/myfile
The output of getfacl
mydir/myfile
is:
# file: mydir/myfile # owner: tux # group: project3 user::rw- group::r-x # effective:r-- group:mascots:r-x # effective:r-- mask::r-- other::---
touch uses a
mode
with the value 0666
when creating new files, which
means that the 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 35.3.3.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
in 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 before any process or application is 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 required permissions, a randomly selected entry triggers the final result “access denied”.