Contents
Abstract
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 the traditional permission concept allows.
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 as well. They can be viewed at http://wt.xpilot.org/publications/posix.1e/.
The basics of traditional Linux file permissions are explained in Section 18.2, “Users and Access 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 some 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. By means of 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
may 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 will be
archive
. For example, a
backup program that runs with the group ID archive
is able to 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