cron
and at
pam_apparmor
POSIX ACLs (access control lists) can be used as an expansion of the traditional permission concept for file system objects. With ACLs, permissions can be defined more flexibly than with the traditional permission concept.
The term POSIX ACL suggests that this is a true POSIX (portable operating system interface) standard. The respective draft standards POSIX 1003.1e and POSIX 1003.2c have been withdrawn for several reasons. Nevertheless, ACLs (as found on many systems belonging to the Unix family) are based on these drafts and the implementation of file system ACLs (as described in this chapter) follows these two standards.
The permissions of all files included in openSUSE Leap are
carefully chosen. When installing additional software or files,
take great care when setting the permissions. Always use the
-l
option with the command ls
to detect any incorrect file permissions immediately. An incorrect
file attribute does not only mean that files could be changed or
deleted. Modified files could be executed by root
or
services could be hijacked by modifying configuration files. This
increases the danger of an attack.
A openSUSE® Leap system includes the files
permissions
,
permissions.easy
,
permissions.secure
, and
permissions.paranoid
, all in the directory
/etc
. The purpose of these files is to define
special permissions, such as world-writable directories or, for
files, the setuser ID bit. Programs with the setuser ID bit set do
not run with the permissions of the user that launched it, but
with the permissions of the file owner, root
. An
administrator can use the file
/etc/permissions.local
to add their own
settings.
To define one of the available profiles, select /etc/permissions
or consult
man chmod
.
Find detailed information about the traditional file permissions in the
GNU Coreutils Info page, Node File permissions
(info coreutils "File permissions"
). More advanced
features are the setuid, setgid and sticky bit.
In certain situations, the access permissions may be too restrictive.
Therefore, Linux has additional settings that enable the temporary
change of the current user and group identity for a specific action. For
example, the passwd
program normally requires root
permissions to access /etc/passwd
. This file
contains important information, like the home directories of users
and user and group IDs. Thus, a normal user would not be able to change
passwd
, because it would be too dangerous to grant
all users direct access to this file. A possible solution to this
problem is the setuid mechanism. setuid (set user
ID) is a special file attribute that instructs the system to execute
programs marked accordingly under a specific user ID. Consider the
passwd
command:
-rwsr-xr-x 1 root shadow 80036 2004-10-02 11:08 /usr/bin/passwd
You can see the s
that denotes that the setuid bit is
set for the user permission. Through the setuid bit, all users
starting the passwd
command execute it as
root
.
The setuid bit applies to users. However, there is also an equivalent property for groups: the setgid bit. A program for which this bit was set runs under the group ID under which it was saved, no matter which user starts it. Therefore, in a directory with the setgid bit, all newly created files and subdirectories are assigned to the group to which the directory belongs. Consider the following example directory:
drwxrws--- 2 tux archive 48 Nov 19 17:12 backup
You can see the s
that denotes that the setgid bit is
set for the group permission. The owner of the directory and members of
the group archive
can access
this directory. Users that are not members of this group are
“mapped” to the respective group. The effective group ID of
all written files is
archive
. For example, a
backup program that runs with the group ID
archive
can access
this directory even without root privileges.
There is also the sticky bit. It makes a difference
whether it belongs to an executable program or a directory. If it
belongs to a program, a file marked in this way is loaded to RAM to
avoid needing to get it from the hard disk each time it is used. This
attribute is used rarely, because modern hard disks are fast enough. If
this bit is assigned to a directory, it prevents users from deleting
each other's files. Typical examples include the
/tmp
and /var/tmp
directories:
drwxrwxrwt 2 root root 1160 2002-11-19 17:15 /tmp
Traditionally, three permission sets are defined for each file object on
a Linux system. These sets include the read (r
), write
(w
), and execute (x
) permissions
for each of three types of users—the file owner, the group, and
other users. Additionally, it is possible to set the set
user id, the set group id, and the
sticky bit. This lean concept is fully adequate for
most practical cases. However, for more complex scenarios or advanced
applications, system administrators formerly needed to use several
workarounds to circumvent the limitations of the traditional permission
concept.
ACLs can be used as an extension of the traditional file permission concept. They allow the assignment of permissions to individual users or groups even if these do not correspond to the original owner or the owning group. Access control lists are a feature of the Linux kernel and are currently supported by Ext2, Ext3, Ext4, JFS and XFS. Using ACLs, complex scenarios can be realized without implementing complex permission models on the application level.
The advantages of ACLs are evident if you want to replace a Windows
server with a Linux server. Some connected workstations may
continue to run under Windows even after the migration. The Linux system
offers file and print services to the Windows clients with Samba. With
Samba supporting access control lists, user permissions can be configured
both on the Linux server and in Windows with a graphical user interface
(only Windows NT and later). With winbindd
, part of
the Samba suite, it is even possible to assign permissions to users only
existing in the Windows domain without any account on the Linux server.
The conventional POSIX permission concept uses three
classes of users for assigning permissions in the
file system: the owner, 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
).
The user and group access permissions for all kinds of file system objects (files and directories) are determined through ACLs.
Default ACLs can only be applied to directories. They determine the permissions a file system object inherits from its parent directory when it is created.
Each ACL consists of a set of ACL entries. An ACL entry contains a type, a qualifier for the user or group to which the entry refers, and a set of permissions. For certain entry types, the qualifier for the group or users is undefined.
Table 19.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. 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 and 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 19.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.
Type |
Text Form |
---|---|
owner |
|
named user |
|
owning group |
|
named group |
|
mask |
|
other |
|
Entry Type |
Text Form |
Permissions |
---|---|---|
named user |
|
|
mask |
|
|
effective permissions: |
|
Figure 19.1, “Minimum ACL: ACL entries compared to permission bits” and
Figure 19.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.
For a minimum ACL—without mask—the group class permissions are mapped to the ACL entry owning group. This is shown in Figure 19.1, “Minimum ACL: ACL entries compared to permission bits”. For an extended ACL—with mask—the group class permissions are mapped to the mask entry. This is shown in Figure 19.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 through 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.
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 (7
). umask
masks the corresponding permission bits or turns them off. For
details, refer to Section 11.4, “Default umask” or 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. Specifically for the
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::---
Besides 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
. The mask
entry 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 19.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 chmod
to remove the write
permission from the group class bits, the output of
ls
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 ways in which the permissions of a directory's default ACL are passed to the files and subdirectories:
A subdirectory inherits the default ACL of the parent directory both as its default ACL and as an ACL.
A file inherits the default ACL as its 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 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 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 ACL of mysubdir
is an exact reflection of the default ACL of
mydir
. The default ACL that this directory
hands 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 19.4.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 contain the required permissions, a randomly selected entry triggers the final result “access denied”.
ACLs can be used to implement complex permission scenarios that meet
the requirements of modern applications. The traditional permission
concept and ACLs can be combined in a smart manner. The basic file
commands (cp
, mv
,
ls
, etc.) support ACLs, as do Samba and Nautilus.
Vi/Vim and emacs both fully support ACLs by preserving the permissions on
writing files including backups. Many editors and file
managers still lack ACL support. When modifying files with an editor, the
ACLs of files are sometimes preserved and sometimes not, depending on the
backup mode of the editor used. If the editor writes the changes to the
original file, the ACL is preserved. If the editor saves the updated
contents to a new file that is subsequently renamed to the old file name,
the ACLs may be lost, unless the editor supports ACLs. Except for the
star
archiver, there are currently no backup applications
that preserve ACLs.
For more information about ACLs, see the man pages for
getfacl(1)
, acl(5)
, and
setfacl(1)
.