5 The Filesystem
5.6 A CCESS CONTROL LISTS
The 9-bit owner/group/other access control system has proved to be powerful enough to accommodate most administrative needs. Although the system has clear limitations, it’s very much in keeping with the UNIX traditions (some might say,
“former traditions”) of simplicity and predictability.
Virtually all non-UNIX operating systems use a substantially more complicated way of regulating access to files: access control lists, or ACLs. ACLs have no set length and can include permission specifications for multiple users or groups. The more sophisticated systems allow administrators to specify partial sets of permissions or negative permissions; some also have inheritance features that allow access to de-pend on more than one ACL at a time. These systems are clearly more powerful than the traditional UNIX model, but they are also an order of magnitude more complex, both for administrators and for software developers.
See page 126 for more information about the mount command and filesystem mounting.
As a result of efforts to include ACLs in the POSIX specification, many variants of UNIX have come to support a relatively standard ACL mechanism that operates in parallel with the traditional UNIX 9-bit model. Under Linux, ACLs are supported by ext2, ext3, ReiserFS, XFS, and JFS. They are usually disabled by default; use the -o acl option to mount to turn them on.
For completeness, we describe the Linux ACL model here. But don’t be seduced by the pretty colors—ACLs are not necessarily “better” than traditional file permis-sions, and knowledgeable administrators should use them with a degree of trepida-tion. Not only are they complicated and tiresome to use, but they can also cause problems in conjunction with NFS, backup systems, and programs such as text edi-tors. ACLs tend toward entropy and so become unmaintainable over time.
See page 828 for more information about Samba.
Perhaps the most plausible reason for using ACLs is to increase compatibility with other operating systems. In particular, the Samba suite used for file sharing with Windows systems is ACL-aware and makes a good-faith effort to translate between the ACLs of Linux and Windows.
ACL overview
Linux ACLs are a mostly straightforward extension of the standard 9-bit model.
Read, write, and execute permission are the only capabilities the system deals with.
Embellishments such as the setuid and sticky bits are handled exclusively through the traditional mode bits.
The Filesystem
5.6 Access control lists 89
ACLs allow the rwx bits to be set independently for any combination of users and groups. Table 5.8 shows what the individual entries in an ACL can look like.
Users and groups can be identified by name or by UID/GID. The exact number of entries that an ACL can contain varies with the filesystem implementation and ranges from a low of 25 with XFS to a virtually unlimited number with ReiserFS and JFS. The ext2 and ext3 filesystems allow 32 entries, which is probably a reasonable limit for manageability in any case.
The getfacl command displays a file’s current ACL, and the setfacl command mod-ifies or sets it. Use setfacl -bfile to clear the ACL, setfacl -maclspec file to modify or extend it, and setfacl -xaclspec file to delete specific entries in the list. (Omit the permission specification portion of the aclspec when using -x.) The aclspec can con-tain more than one list entry as long as the entries are separated with a comma.
Files with ACLs retain their original mode bits, but consistency is automatically en-forced and the two sets of permissions can never conflict. The following example demonstrates that the ACL entries update automatically in response to changes made with chmod:
$touch /tmp/example
$ls -l /tmp/example
-rw-rw-r-- 1 garth garth 0 Jun 14 15:57 /tmp/example
$getfacl /tmp/example
getfacl: Removing leading '/' from absolute path names
# file: tmp/example
# owner: garth
# group: garth user::rw- group::rw-
other::r--$chmod 640 /tmp/example
$getfacl --omit-header /tmp/example
user::rw- group::r--
other::---Table 5.8 Entries that can appear in an access control list
Format Example Sets permissions for
user ::perms user::rw- The file’s owner
user :username :perms user:trent:rw- A specific user
group: :perms group::r-x The group that owns the file group:groupname :perms group:staff:rw- A specific group
other: :perms other::--- All others
mask::perms mask::rwx All but owner and othera
a. Masks are somewhat tricky and are explained later in this section.
This enforced consistency allows older software with no awareness of ACLs to play reasonably well in the ACL world. However, there’s a twist. Even though the group::
ACL entry in the example above appears to be tracking the middle set of traditional mode bits, this will not always be the case.
To understand why, suppose that a legacy program clears the write bits within all three permission sets of the traditional mode (e.g., chmod ugo-wfile). The inten-tion is clearly to make the file unwritable by anyone. But what if the resulting ACL were to look like this?
user::r-- group::r-- group:staff:rw-
other::r--From the perspective of legacy programs, the file appears to be unmodifiable, yet it is actually writable by anyone in group staff. Not good. To reduce the chance of am-biguity and misunderstandings, Linux has adopted the following rules:
•
The user:: and other:: ACL entries are by definition identical to the “owner”and “other” permission bits from the traditional file mode. Changing the mode changes the corresponding ACL entries, and vice versa.
•
In all cases, the effective access permission afforded to the file’s owner and to users not mentioned in another way are those specified in the user:: and other:: ACL entries, respectively.•
If a file has no explicitly defined ACL or has an ACL that consists only of one user::, one group::, and one other:: entry, these ACL entries are identi-cal to the three sets of traditional permission bits. This is the case illus-trated in the getfacl example above. (Such an ACL is termed “minimal”and need not actually be implemented as a logically separate ACL.)
•
In more complex ACLs, the traditional group permission bits correspond to a special ACL entry called “mask” rather than the group:: ACL entry.The mask limits the access that the ACL can confer upon all named users, all named groups, and the default group.
In other words, the mask specifies an upper bound on the access that the ACL can assign to individual groups and users. It is conceptually similar to the umask, ex-cept that the ACL mask is always in effect and specifies the allowed permissions rather than the permissions to be denied. ACL entries for named users, named groups, and the default group can include permissions bits that are not present in the mask, but the kernel simply ignores them.
As a result, the traditional mode bits can never understate the access allowed by the ACL as a whole. Furthermore, clearing a bit from the group portion of the traditional mode clears the corresponding bit in the ACL mask and thereby forbids this permis-sion to everyone but the file’s owner and those who fall in the category of “other.”
The Filesystem
5.6 Access control lists 91
When the ACL shown in the previous example is expanded to include entries for a specific user and group, setfacl automatically supplies an appropriate mask:
$setfacl -m user::r,user:trent:rw,group:admin:rw /tmp/example
$ls -l /tmp/example
-r--rw----+ 1 garth staff 0 Jun 14 15:57 /tmp/example
$getfacl --omit-header /tmp/example
user::r-- user:trent:rw- group::r-- group:admin:rw- mask::rw-
other::---As seen here, setfacl generates a mask that allows all the permissions granted in the ACL to take effect. If you want to set the mask by hand, include it in the ACL entry list given to setfacl or use the -n option to prevent setfacl from regenerating it.
When access is attempted, the effective UID is compared to the UID that owns the file. If they are the same, access is determined by the user:: permissions in the ACL.
Otherwise, if there is a matching user-specific ACL entry, permissions are deter-mined by that entry in combination with the ACL mask. If no user-specific entry is available, the filesystem tries to locate a valid group-related entry that provides the requested access; such entries are also processed in conjunction with the ACL mask.
If no matching entry can be found, the other:: entry prevails.
If you use the traditional chmod command to manipulate the group permissions on an ACL-bearing file, be aware that your changes affect only the mask. To continue the previous example:
$chmod 770 /tmp/example
$ls -l /tmp/example
-rwxrwx---+ 1 garth staff 0 Jun 14 15:57 /tmp/example
$getfacl --omit-header /tmp/example user::rwx
user:trent:rw- group::r-- group:admin:rw-mask::rwx
other::---The ls output in this case is misleading. Despite the apparently generous group per-missions, no one actually has permission to execute the file by reason of group mem-bership. To grant such permission, you must edit the ACL itself.
Default entries
In addition to the ACL entry types listed in Table 5.8, the ACLs for directories can include “default” entries that are propagated to the ACLs of newly created files and subdirectories created within them. Subdirectories receive these entries both in the
form of active ACL entries and in the form of defaults. Therefore, the original defaults may eventually propagate down through several layers of the directory hierarchy.
The connection between the parent and child ACLs does not continue once the de-fault entries have been copied. If the parent’s dede-fault entries change, the changes are not reflected in the ACLs of existing subdirectories.
5.7 E
XERCISESE5.1 What is a umask? Create a umask that would give no permissions to the group or the world.
E5.2 What is the difference between hard links and symbolic (soft) links?
When is it appropriate to use one or the other?
E5.3 Read the man page for the /etc/fstab file. Write an entry that automati-cally mounts a Windows NTFS partition, /dev/hda1, at startup. Use the mount point /mnt/win_c.
E5.4 When installing a Linux system, it’s important to partition the hard drive such that each filesystem (/var,/usr, etc.) has adequate space for both current and future needs. The “Foobar Linux” distribution uses the fol-lowing defaults:
/ 100MB
/var 50MB
/boot 10MB
<swap> 128MB
/usr remaining space
What are some potential problems with this arrangement on a busy server box?
E5.5 Why is it a good idea to put some partitions (such as /var,/home, and swap) on a separate drive from other data files and programs? What about /tmp? Give specific reasons for each of the filesystems listed.
E5.6 Write a script that finds all the hard links on a filesystem.
E5.7 Give commands to accomplish the following tasks.
a) Set the permissions on the file README to read/write for the owner and read for everyone else.
b) Turn on a file’s setuid bit without changing (or knowing) the current permissions.
c) List the contents of the current directory, sorting by modification time and listing the most recently modified file last.
d) Change the group of a file called shared from “user” to “friends”.
93
Adding New Users