Table 12-1 ACL Entry Types
owner |
user::rwx
|
named user |
user:name:rwx
|
owning group |
group::rwx
|
named group |
group:name:rwx
|
mask |
mask::rwx
|
other |
other::rwx
|
12.4.1 ACL Entries and File Mode Permission Bits
Figure 12-1 and Figure 12-2 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 12-1. In the case of an extended
ACL—with mask—the group class permissions are
mapped to the mask entry. This is shown in Figure 12-2.
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.
12.4.2 A Directory with an Access ACL
With getfacl and setfacl
on the command line, you can access ACLs. The usage of these
commands is demonstrated in the following example.
Before creating 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
umask man page.
mkdir mydir creates the
mydir directory with the default permissions as
set by umask. Use ls -dl
mydir to check whether 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 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 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 12-2). 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.
12.4.4 The ACL Check Algorithm
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
.