ACC SHELL
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 10. Access Control Lists in Linux</title><link rel="stylesheet" href="susebooks.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Documentation"><link rel="up" href="part.local_security.html" title="Part II. Local Security"><link rel="prev" href="cha.security.policykit.html" title="Chapter 9. PolicyKit"><link rel="next" href="cha.security.cryptofs.html" title="Chapter 11. Encrypting Partitions and Files"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.security.html">Security Guide</a><span class="breadcrumbs-sep"> > </span><a href="part.local_security.html">Local Security</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="Chapter 9. PolicyKit" href="cha.security.policykit.html"><span>◀</span></a> <a accesskey="n" title="Chapter 11. Encrypting Partitions and Files" href="cha.security.cryptofs.html"><span>▶</span></a></strong></p></div></td></tr></table></div><div class="chapter" title="Chapter 10. Access Control Lists in Linux"><div class="titlepage"><div><div><h2 class="title"><a name="cha.security.acls"></a>Chapter 10. Access Control Lists in Linux<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#cha.security.acls">¶</a></span></h2></div></div></div><div class="toc"><p><b>Contents</b></p><dl><dt><span class="sect1"><a href="cha.security.acls.html#sec.security.acls.traditional">10.1. Traditional File Permissions</a></span></dt><dt><span class="sect1"><a href="cha.security.acls.html#sec.security.acls.intro">10.2. Advantages of ACLs</a></span></dt><dt><span class="sect1"><a href="cha.security.acls.html#sec.security.acls.defs">10.3. Definitions</a></span></dt><dt><span class="sect1"><a href="cha.security.acls.html#sec.security.acls.handle">10.4. Handling ACLs</a></span></dt><dt><span class="sect1"><a href="cha.security.acls.html#sec.security.acls.future">10.5. ACL Support in Applications</a></span></dt><dt><span class="sect1"><a href="cha.security.acls.html#sec.security.acls.info">10.6. For More Information</a></span></dt></dl></div><a class="indexterm" name="idx.ACLs"></a><div class="abstract" title="Abstract"><p class="title"><b>Abstract</b></p><p>
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.
</p></div><a class="indexterm" name="idx.file_systems_access_control_lists"></a><a class="indexterm" name="idx.permissions_ACLs"></a><p>
The term <span class="emphasis"><em>POSIX ACL</em></span> suggests that this is a true POSIX
(<span class="emphasis"><em>portable operating system interface</em></span>) 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, as well.
</p><div class="sect1" title="10.1. Traditional File Permissions"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.acls.traditional"></a>10.1. Traditional File Permissions<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.acls.traditional">¶</a></span></h2></div></div></div><p>
Find detailed information about the traditional file permissions in the
GNU Coreutils Info page, Node <span class="emphasis"><em>File permissions</em></span>
(<span class="command"><strong>info coreutils "File permissions"</strong></span>). More advanced
features are the setuid, setgid, and sticky bit.
</p><div class="sect2" title="10.1.1. The setuid Bit"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.acls.traditional.setuid"></a>10.1.1. The setuid Bit<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.acls.traditional.setuid">¶</a></span></h3></div></div></div><p>
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 <span class="command"><strong>passwd</strong></span> program normally requires root
permissions to access <code class="filename">/etc/passwd</code>. This file
contains some important information, like the home directories of users
and user and group IDs. Thus, a normal user would not be able to change
<code class="filename">passwd</code>, because it would be too dangerous to grant
all users direct access to this file. A possible solution to this
problem is the <span class="emphasis"><em>setuid</em></span> 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
<span class="command"><strong>passwd</strong></span> command:
</p><pre class="screen">-rwsr-xr-x 1 root shadow 80036 2004-10-02 11:08 /usr/bin/passwd</pre><p>
You can see the <code class="literal">s</code> that denotes that the setuid bit is
set for the user permission. By means of the setuid bit, all users
starting the <span class="command"><strong>passwd</strong></span> command execute it as
<code class="systemitem">root</code>.
</p></div><div class="sect2" title="10.1.2. The setgid Bit"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.acls.traditional.setgid"></a>10.1.2. The setgid Bit<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.acls.traditional.setgid">¶</a></span></h3></div></div></div><p>
The setuid bit applies to users. However, there is also an equivalent
property for groups: the <span class="emphasis"><em>setgid</em></span> 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:
</p><pre class="screen">drwxrws--- 2 tux archive 48 Nov 19 17:12 backup</pre><p>
You can see the <code class="literal">s</code> that denotes that the setgid bit is
set for the group permission. The owner of the directory and members of
the group <code class="systemitem">archive</code> may
access this directory. Users that are not members of this group are
<span class="quote">“<span class="quote">mapped</span>”</span> to the respective group. The effective group ID of
all written files will be
<code class="systemitem">archive</code>. For example, a
backup program that runs with the group ID
<code class="systemitem">archive</code> is able to access
this directory even without root privileges.
</p></div><div class="sect2" title="10.1.3. The Sticky Bit"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.acls.traditional.sticky"></a>10.1.3. The Sticky Bit<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.acls.traditional.sticky">¶</a></span></h3></div></div></div><p>
There is also the <span class="emphasis"><em>sticky bit</em></span>. 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
<code class="filename">/tmp</code> and <code class="filename">/var/tmp</code> directories:
</p><pre class="screen">drwxrwxrwt 2 root root 1160 2002-11-19 17:15 /tmp</pre></div></div><div class="sect1" title="10.2. Advantages of ACLs"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.acls.intro"></a>10.2. Advantages of ACLs<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.acls.intro">¶</a></span></h2></div></div></div><p>
Traditionally, three permission sets are defined for each file object on
a Linux system. These sets include the read (<code class="literal">r</code>), write
(<code class="literal">w</code>), and execute (<code class="literal">x</code>) permissions
for each of three types of users—the file owner, the group, and
other users. In addition to that, it is possible to set the <span class="emphasis"><em>set
user id</em></span>, the <span class="emphasis"><em>set group id</em></span>, and the
<span class="emphasis"><em>sticky</em></span> bit. This lean concept is fully adequate for
most practical cases. However, for more complex scenarios or advanced
applications, system administrators formerly had to use a number of
workarounds to circumvent the limitations of the traditional permission
concept.
</p><p>
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 ReiserFS, Ext2, Ext3, JFS, and XFS. Using
ACLs, complex scenarios can be realized without implementing complex
permission models on the application level.
</p><p>
The advantages of ACLs are evident if you want to replace a Windows
server with a Linux server. Some of the 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 <span class="command"><strong>winbindd</strong></span>, 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.
</p></div><div class="sect1" title="10.3. Definitions"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.acls.defs"></a>10.3. Definitions<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.acls.defs">¶</a></span></h2></div></div></div><a class="indexterm" name="id583982"></a><div class="variablelist"><dl><dt><span class="term">User Class</span></dt><dd><p>
The conventional POSIX permission concept uses three
<span class="emphasis"><em>classes</em></span> 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 (<code class="literal">r</code>), write (<code class="literal">w</code>), and execute
(<code class="literal">x</code>).
</p></dd><dt><span class="term">ACL</span></dt><dd><p>
<a class="indexterm" name="id584037"></a> The user and group access permissions for all kinds of
file system objects (files and directories) are determined by means of
ACLs.
</p></dd><dt><span class="term">Default ACL<a class="indexterm" name="id584058"></a></span></dt><dd><p>
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.
</p></dd><dt><span class="term">ACL Entry</span></dt><dd><p>
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 some entry types, the qualifier for the
group or users is undefined.
</p></dd></dl></div></div><div class="sect1" title="10.4. Handling ACLs"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.acls.handle"></a>10.4. Handling ACLs<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.acls.handle">¶</a></span></h2></div></div></div><a class="indexterm" name="id584106"></a><a class="indexterm" name="id584114"></a><p>
<a class="xref" href="cha.security.acls.html#tab.entrytype" title="Table 10.1. ACL Entry Types">Table 10.1, “ACL Entry Types”</a> summarizes the six possible types of ACL
entries, each defining permissions for a user or a group of users. The
<span class="emphasis"><em>owner</em></span> entry defines the permissions of the user
owning the file or directory. The <span class="emphasis"><em>owning group</em></span> entry
defines the permissions of the file's owning group. The superuser can
change the owner or owning group with <span class="command"><strong>chown</strong></span> or
<span class="command"><strong>chgrp</strong></span>, in which case the owner and owning group
entries refer to the new owner and owning group. Each <span class="emphasis"><em>named
user</em></span> entry defines the permissions of the user specified in
the entry's qualifier field. Each <span class="emphasis"><em>named group</em></span> 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 <span class="emphasis"><em>other</em></span> entry defines the
permissions of all other users.
</p><p>
The <span class="emphasis"><em>mask</em></span> 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
<a class="xref" href="cha.security.acls.html#tab.mask" title="Table 10.2. Masking Access Permissions">Table 10.2, “Masking Access Permissions”</a> demonstrates this mechanism.
</p><p>
There are two basic classes of ACLs: A <span class="emphasis"><em>minimum</em></span> 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 <span class="emphasis"><em>extended</em></span> ACL goes beyond this. It
must contain a mask entry and may contain several entries of the named
user and named group types.
</p><div class="table"><a name="tab.entrytype"></a><p class="title"><b>Table 10.1. ACL Entry Types</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#tab.entrytype">¶</a></span></p><div class="table-contents"><table summary="ACL Entry Types" border="1"><colgroup><col><col></colgroup><thead><tr><th>
<p>
Type
</p>
</th><th>
<p>
Text Form
</p>
</th></tr></thead><tbody><tr><td>
<p>
owner
</p>
</td><td>
<p>
<code class="literal">user::rwx</code>
</p>
</td></tr><tr><td>
<p>
named user
</p>
</td><td>
<p>
<code class="literal">user:name:rwx</code>
</p>
</td></tr><tr><td>
<p>
owning group
</p>
</td><td>
<p>
<code class="literal">group::rwx</code>
</p>
</td></tr><tr><td>
<p>
named group
</p>
</td><td>
<p>
<code class="literal">group:name:rwx</code>
</p>
</td></tr><tr><td>
<p>
mask
</p>
</td><td>
<p>
<code class="literal">mask::rwx</code>
</p>
</td></tr><tr><td>
<p>
other
</p>
</td><td>
<p>
<code class="literal">other::rwx</code>
</p>
</td></tr></tbody></table></div></div><br class="table-break"><div class="table"><a name="tab.mask"></a><p class="title"><b>Table 10.2. Masking Access Permissions</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#tab.mask">¶</a></span></p><div class="table-contents"><table summary="Masking Access Permissions" border="1"><colgroup><col><col><col></colgroup><thead><tr><th>
<p>
Entry Type
</p>
</th><th>
<p>
Text Form
</p>
</th><th>
<p>
Permissions
</p>
</th></tr></thead><tbody><tr><td>
<p>
named user
</p>
</td><td>
<p>
<code class="literal">user:geeko:r-x</code>
</p>
</td><td>
<p>
<code class="literal">r-x</code>
</p>
</td></tr><tr><td>
<p>
mask
</p>
</td><td>
<p>
<code class="literal">mask::rw-</code>
</p>
</td><td>
<p>
<code class="literal">rw-</code>
</p>
</td></tr><tr><td>
<p></p>
</td><td>
<p>
effective permissions:
</p>
</td><td>
<p>
<code class="literal">r--</code>
</p>
</td></tr></tbody></table></div></div><br class="table-break"><div class="sect2" title="10.4.1. ACL Entries and File Mode Permission Bits"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.acls.handle.fmbits"></a>10.4.1. ACL Entries and File Mode Permission Bits<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.acls.handle.fmbits">¶</a></span></h3></div></div></div><a class="indexterm" name="id584528"></a><p>
<a class="xref" href="cha.security.acls.html#fig.acls.map.mini" title="Figure 10.1. Minimum ACL: ACL Entries Compared to Permission Bits">Figure 10.1, “Minimum ACL: ACL Entries Compared to Permission Bits”</a> and
<a class="xref" href="cha.security.acls.html#fig.acls.map.ext" title="Figure 10.2. Extended ACL: ACL Entries Compared to Permission Bits">Figure 10.2, “Extended ACL: ACL Entries Compared to Permission Bits”</a> 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 <span class="command"><strong>ls</strong></span>
<code class="option">-l</code>). In both cases, the <span class="emphasis"><em>owner
class</em></span> permissions are mapped to the ACL entry owner.
<span class="emphasis"><em>Other class</em></span> permissions are mapped to the
respective ACL entry. However, the mapping of the <span class="emphasis"><em>group
class</em></span> permissions is different in the two cases.
</p><div class="figure"><a name="fig.acls.map.mini"></a><p class="title"><b>Figure 10.1. Minimum ACL: ACL Entries Compared to Permission Bits</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.acls.map.mini">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/acls_map_mini.png" width="100%" alt="Minimum ACL: ACL Entries Compared to Permission Bits"></td></tr></table></div></div></div><br class="figure-break"><p>
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
<a class="xref" href="cha.security.acls.html#fig.acls.map.mini" title="Figure 10.1. Minimum ACL: ACL Entries Compared to Permission Bits">Figure 10.1, “Minimum ACL: ACL Entries Compared to Permission Bits”</a>. In the case of an extended
ACL—with mask—the group class permissions are mapped to the
mask entry. This is shown in <a class="xref" href="cha.security.acls.html#fig.acls.map.ext" title="Figure 10.2. Extended ACL: ACL Entries Compared to Permission Bits">Figure 10.2, “Extended ACL: ACL Entries Compared to Permission Bits”</a>.
</p><div class="figure"><a name="fig.acls.map.ext"></a><p class="title"><b>Figure 10.2. Extended ACL: ACL Entries Compared to Permission Bits</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.acls.map.ext">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/acls_map_ext.png" width="100%" alt="Extended ACL: ACL Entries Compared to Permission Bits"></td></tr></table></div></div></div><br class="figure-break"><p>
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 <span class="quote">“<span class="quote">fine adjustments</span>”</span> made with an ACL. Changes
made to the permission bits are reflected by the ACL and vice versa.
</p></div><div class="sect2" title="10.4.2. A Directory with an ACL"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.acls.handle.accacl"></a>10.4.2. A Directory with an ACL<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.acls.handle.accacl">¶</a></span></h3></div></div></div><a class="indexterm" name="id584700"></a><p>
With <span class="command"><strong>getfacl</strong></span> and <span class="command"><strong>setfacl</strong></span> on the
command line, you can access ACLs. The usage of these commands is
demonstrated in the following example.
</p><p>
Before creating the directory, use the <span class="command"><strong>umask</strong></span> command
to define which access permissions should be masked each time a file
object is created. The command <span class="command"><strong>umask</strong></span>
<code class="option">027</code> sets the default permissions by giving the owner
the full range of permissions (<code class="literal">0</code>), denying the group
write access (<code class="literal">2</code>), and giving other users no
permissions at all (<code class="literal">7</code>). <span class="command"><strong>umask</strong></span>
actually masks the corresponding permission bits or turns them off. For
details, consult the <span class="command"><strong>umask</strong></span> man page.
</p><p>
<span class="command"><strong>mkdir mydir</strong></span> creates the <code class="filename">mydir</code>
directory with the default permissions as set by
<span class="command"><strong>umask</strong></span>. Use <span class="command"><strong>ls <code class="option">-dl
mydir</code></strong></span> to check whether all permissions were assigned
correctly. The output for this example is:
</p><pre class="screen">drwxr-x--- ... tux project3 ... mydir</pre><p>
With <span class="command"><strong>getfacl <code class="option">mydir</code></strong></span>, check the
initial state of the ACL. This gives information like:
</p><pre class="screen"># file: mydir
# owner: tux
# group: project3
user::rwx
group::r-x
other::---</pre><p>
<a class="indexterm" name="id584801"></a> 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 <span class="command"><strong>getfacl</strong></span> command does not produce any
information you could not have obtained with <span class="command"><strong>ls</strong></span>.
</p><p>
Modify the ACL to assign read, write, and execute permissions to an
additional user <code class="literal">geeko</code> and an additional group
<code class="literal">mascots</code> with:
</p><pre class="screen">setfacl -m user:geeko:rwx,group:mascots:rwx mydir</pre><a class="indexterm" name="id584838"></a><p>
The option <code class="option">-m</code> prompts <span class="command"><strong>setfacl</strong></span> 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 <span class="command"><strong>getfacl</strong></span> command to take a
look at the resulting ACL.
</p><pre class="screen"># file: mydir
# owner: tux
# group: project3
user::rwx
user:geeko:rwx
group::r-x
group:mascots:rwx
mask::rwx
other::---</pre><p>
<a class="indexterm" name="id584872"></a> In addition to the entries initiated for the user
<code class="literal">geeko</code> and the group <code class="literal">mascots</code>, a
mask entry has been generated. This mask entry is set automatically so
that all permissions are effective. <span class="command"><strong>setfacl</strong></span>
automatically adapts existing mask entries to the settings modified,
unless you deactivate this feature with <code class="literal">-n</code>. 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 <span class="command"><strong>ls</strong></span>
<code class="option">-dl mydir</code> now correspond to the <code class="literal">mask</code>
entry.
</p><pre class="screen">drwxrwx---+ ... tux project3 ... mydir</pre><p>
The first column of the output contains an additional
<code class="literal">+</code> to indicate that there is an
<span class="emphasis"><em>extended</em></span> ACL for this item.
</p><p>
According to the output of the <span class="command"><strong>ls</strong></span> command, the
permissions for the mask entry include write access. Traditionally, such
permission bits would mean that the owning group (here
<code class="literal">project3</code>) also has write access to the directory
<code class="filename">mydir</code>. 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
<code class="literal">r-x</code> in our example (see <a class="xref" href="cha.security.acls.html#tab.mask" title="Table 10.2. Masking Access Permissions">Table 10.2, “Masking Access Permissions”</a>).
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.
</p><p>
Edit the mask entry with <span class="command"><strong>setfacl</strong></span> or
<span class="command"><strong>chmod</strong></span>. For example, use <span class="command"><strong>chmod <code class="option">g-w
mydir</code></strong></span>. <span class="command"><strong>ls <code class="option">-dl
mydir</code></strong></span> then shows:
</p><pre class="screen">drwxr-x---+ ... tux project3 ... mydir</pre><p>
<span class="command"><strong>getfacl <code class="option">mydir</code></strong></span> provides the following
output:
</p><pre class="screen"># 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::---</pre><p>
After executing the <span class="command"><strong>chmod</strong></span> command to remove the write
permission from the group class bits, the output of the
<span class="command"><strong>ls</strong></span> command is sufficient to see that the mask bits
must have changed accordingly: write permission is again limited to the
owner of <code class="filename">mydir</code>. The output of the
<span class="command"><strong>getfacl</strong></span> 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 <span class="command"><strong>chmod <code class="option">g+w mydir</code></strong></span>.
</p></div><div class="sect2" title="10.4.3. A Directory with a Default ACL"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.acls.handle.defacl"></a>10.4.3. A Directory with a Default ACL<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.acls.handle.defacl">¶</a></span></h3></div></div></div><a class="indexterm" name="id585039"></a><p>
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.
</p><div class="sect3" title="10.4.3.1. Effects of a Default ACL"><div class="titlepage"><div><div><h4 class="title"><a name="sec.security.acls.handle.defacl.eff"></a>10.4.3.1. Effects of a Default ACL<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.acls.handle.defacl.eff">¶</a></span></h4></div></div></div><a class="indexterm" name="id585063"></a><p>
There are two ways in which the permissions of a directory's default
ACL are passed to the files and subdirectories:
</p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
A subdirectory inherits the default ACL of the parent directory both
as its default ACL and as an ACL.
</p></li><li class="listitem" style="list-style-type: disc"><p>
A file inherits the default ACL as its ACL.
</p></li></ul></div><p>
All system calls that create file system objects use a
<code class="literal">mode</code> 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
<code class="literal">umask</code> are subtracted from the permissions as passed
by the <code class="literal">mode</code> 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
<code class="literal">mode</code> parameter and those that are defined in the
default ACL. The <code class="literal">umask</code> is disregarded in this case.
</p></div><div class="sect3" title="10.4.3.2. Application of Default ACLs"><div class="titlepage"><div><div><h4 class="title"><a name="sec.security.acls.handle.defacl.prac"></a>10.4.3.2. Application of Default ACLs<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.acls.handle.defacl.prac">¶</a></span></h4></div></div></div><p>
The following three examples show the main operations for directories
and default ACLs:
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li><p>
Add a default ACL to the existing directory
<code class="filename">mydir</code> with:
</p><pre class="screen">setfacl -d -m group:mascots:r-x mydir</pre><p>
The option <code class="literal">-d</code> of the <span class="command"><strong>setfacl</strong></span>
command prompts <span class="command"><strong>setfacl</strong></span> to perform the following
modifications (option <code class="literal">-m</code>) in the default ACL.
</p><p>
Take a closer look at the result of this command:
</p><pre class="screen">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::---</pre><p>
<span class="command"><strong>getfacl</strong></span> returns both the ACL and the default ACL.
The default ACL is formed by all lines that start with
<code class="literal">default</code>. Although you merely executed the
<span class="command"><strong>setfacl</strong></span> command with an entry for the
<code class="literal">mascots</code> group for the default ACL,
<span class="command"><strong>setfacl</strong></span> 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.
</p></li><li><p>
In the next example, use <span class="command"><strong>mkdir</strong></span> to create a
subdirectory in <code class="filename">mydir</code>, which inherits the
default ACL.
</p><pre class="screen">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::---</pre><p>
As expected, the newly-created subdirectory
<code class="filename">mysubdir</code> has the permissions from the default
ACL of the parent directory. The ACL of <code class="filename">mysubdir</code>
is an exact reflection of the default ACL of
<code class="filename">mydir</code>. The default ACL that this directory will
hand down to its subordinate objects is also the same.
</p></li><li><p>
Use <span class="command"><strong>touch</strong></span> to create a file in the
<code class="filename">mydir</code> directory, for example, <span class="command"><strong>touch
<code class="option">mydir/myfile</code></strong></span>. <span class="command"><strong>ls <code class="option">-l
mydir/myfile</code></strong></span> then shows:
</p><pre class="screen">-rw-r-----+ ... tux project3 ... mydir/myfile</pre><p>
The output of <span class="command"><strong>getfacl
<code class="option">mydir/myfile</code></strong></span> is:
</p><pre class="screen"># file: mydir/myfile
# owner: tux
# group: project3
user::rw-
group::r-x # effective:r--
group:mascots:r-x # effective:r--
mask::r--
other::---</pre><p>
<span class="command"><strong>touch</strong></span> uses a <code class="literal">mode</code> with the
value <code class="literal">0666</code> 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
<span class="command"><strong>umask</strong></span> or in the default ACL (see
<a class="xref" href="cha.security.acls.html#sec.security.acls.handle.defacl.eff" title="10.4.3.1. Effects of a Default ACL">Section 10.4.3.1, “Effects of a Default ACL”</a>). In
effect, this means that all access permissions not contained in the
<code class="literal">mode</code> 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 <code class="literal">mode</code>.
</p><p>
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
<span class="command"><strong>mask</strong></span> mechanism guarantees that the right users and
groups can execute them as desired.
</p></li></ol></div></div></div><div class="sect2" title="10.4.4. The ACL Check Algorithm"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.acls.handle.alg"></a>10.4.4. The ACL Check Algorithm<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.acls.handle.alg">¶</a></span></h3></div></div></div><a class="indexterm" name="id585362"></a><p>
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.
</p><p>
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 <span class="quote">“<span class="quote">access
granted</span>”</span>. Likewise, if none of the suitable group entries contain
the required permissions, a randomly selected entry triggers the final
result <span class="quote">“<span class="quote">access denied</span>”</span>.
</p></div></div><div class="sect1" title="10.5. ACL Support in Applications"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.acls.future"></a>10.5. ACL Support in Applications<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.acls.future">¶</a></span></h2></div></div></div><a class="indexterm" name="id585404"></a><p>
ACLs can be used to implement very 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 (<span class="command"><strong>cp</strong></span>, <span class="command"><strong>mv</strong></span>,
<span class="command"><strong>ls</strong></span>, etc.) support ACLs, as do Samba and Konqueror.
</p><p>
Unfortunately, many editors and file managers still lack ACL support.
When copying files with Emacs, for instance, the ACLs of these files are
lost. 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 filename, the ACLs may be
lost, unless the editor supports ACLs. Except for the star archiver,
there are currently no backup applications that preserve ACLs.
</p></div><div class="sect1" title="10.6. For More Information"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.acls.info"></a>10.6. For More Information<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.acls.info">¶</a></span></h2></div></div></div><p>
For more information about ACLs, see the man pages for
<span class="command"><strong>getfacl(1)</strong></span>, <span class="command"><strong>acl(5)</strong></span>, and
<span class="command"><strong>setfacl(1)</strong></span>.
</p><a class="indexterm" name="id585465"></a><a class="indexterm" name="id585471"></a><a class="indexterm" name="id585476"></a></div></div><div class="navfooter"><table width="100%" summary="Navigation footer" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.security.html">Security Guide</a><span class="breadcrumbs-sep"> > </span><a href="part.local_security.html">Local Security</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="Chapter 9. PolicyKit" href="cha.security.policykit.html"><span>◀</span></a> <a accesskey="n" title="Chapter 11. Encrypting Partitions and Files" href="cha.security.cryptofs.html"><span>▶</span></a></strong></p></div></td></tr></table></div></body></html>
ACC SHELL 2018