A practical guide to Fedora and Red Hat Enterprise Linux, 7th Edition (2014)

Part II: Using Fedora and Red Hat Enterprise Linux

Chapter 6. The Linux Filesystem

In This Chapter

The Hierarchical Filesystem

Ordinary Files and Directory Files

Pathnames

Relative Pathnames

Working with Directories

Important Standard Directories and Files

Access Permissions

ACLs: Access Control Lists

Hard Links

Symbolic Links

Objectives

After reading this chapter you should be able to:

Define hierarchical filesystem, ordinary files, directory files, home directory, working directory, and parent directory

List best practices for filenames

Determine the name of the working directory

Explain the difference between absolute and relative pathnames

Create and remove directories

List files in a directory, remove files from a directory, and copy and move files between directories

List and describe the uses of standard Linux directories and files

View and interpret file and directory ownership and permissions

Modify file and directory permissions

Expand access control using ACLs

Describe the uses, differences, and methods of creating hard links and symbolic links

A filesystem is a set of data structures (page 1245) that usually resides on part of a disk and that holds directories of files. Filesystems store user and system data that are the basis of users’ work on the system and the system’s existence. This chapter discusses the organization and terminology of the Linux filesystem, defines ordinary and directory files, and explains the rules for naming them. It also shows how to create and delete directories, move through the filesystem, and use absolute and relative pathnames to access files in various directories. It includes a discussion of important files and directories as well as file access permissions and ACLs (Access Control Lists), which allow you to share selected files with specified users. It concludes with a discussion of hard and symbolic links, which can make a single file appear in more than one directory.

In addition to reading this chapter, you can refer to the df info page and to the fsck, mkfs, and tune2fs man pages for more information on filesystems. For information on additional important Linux files, see “Important Files and Directories” on page 502.

The Hierarchical Filesystem

Family tree

A hierarchical (page 1253) structure frequently takes the shape of a pyramid. One example of this type of structure is found by tracing a family’s lineage: A couple has a child, who might in turn have several children, each of whom might have more children. This hierarchical structure is called a family tree (Figure 6-1).

Figure 6-1 A family tree

Directory tree

Like the family tree it resembles, the Linux filesystem is called a tree. It consists of a set of connected files. This structure allows you to organize files so you can easily find any particular one. On a standard Linux system, each user starts with one directory, to which the user can add subdirectories to any desired level. By creating multiple levels of subdirectories, a user can expand the structure as needed.

Subdirectories

Typically each subdirectory is dedicated to a single subject, such as a person, project, or event. The subject dictates whether a subdirectory should be subdivided further. For example, Figure 6-2 shows a secretary’s subdirectory named correspond. This directory contains three subdirectories:business, memos, and personal. The business directory contains files that store each letter the secretary types. If you expect many letters to go to one client, as is the case with milk_co, you can dedicate a subdirectory to that client.

Figure 6-2 A secretary’s directories

One major strength of the Linux filesystem is its ability to adapt to users’ needs. You can take advantage of this strength by strategically organizing your files so they are most convenient and useful for you.

Ordinary Files and Directory Files

Like a family tree, the tree representing the filesystem is usually pictured upside down with its root at the top. Figures 6-2 and 6-3 (next page) show that the tree “grows” downward from the root with paths connecting the root to each of the other files. At the end of each path is either an ordinary file or a directory file. Special files, which can also appear at the ends of paths, are described on page 515. Ordinary files, or simply files, appear at the ends of paths that cannot support other paths. Directory files, also referred to as directories or folders, are the points that other paths can branch off from. (Figures 6-2 and 6-3 show some empty directories.) When you refer to the tree, up is toward the root and down is away from the root. Directories directly connected by a path are called parents (closer to the root) and children (farther from the root). A pathname is a series of names that trace a path along branches from one file to another. See page 181 for more information about pathnames.

Figure 6-3 Directories and ordinary files

Filenames

Every file has a filename. The maximum length of a filename varies with the type of filesystem; Linux supports several types of filesystems. Although most of today’s filesystems allow files with names up to 255 characters long, some filesystems restrict filenames to fewer characters. Although you can use almost any character in a filename, you will avoid confusion if you choose characters from the following list:

• Uppercase letters (A–Z)

• Lowercase letters (a–z)

• Numbers (0–9)

• Underscore (_)

• Period (.)

• Comma (,)

Like the children of one parent, no two files in the same directory can have the same name. (Parents give their children different names because it makes good sense, but Linux requires it.) Files in different directories, like the children of different parents, can have the same name.

The filenames you choose should mean something. Too often a directory is filled with important files with such unhelpful names as hold1, wombat, and junk, not to mention foo and foobar. Such names are poor choices because they do not help you recall what you stored in a file. The following filenames conform to the suggested syntax and convey information about the contents of the file:

• correspond

• january

• davis

• reports

• 2001

• acct_payable

Filename length

When you share your files with users on other systems, you might need to make long filenames differ within the first few characters. Systems running DOS or older versions of Windows have an 8-character filename body length limit and a 3-character filename extension length limit. Some UNIX systems have a 14-character limit, and older Macintosh systems have a 31-character limit. If you keep filenames short, they are easy to type; later you can add extensions to them without exceeding the shorter limits imposed by some filesystems. The disadvantage of short filenames is that they are typically less descriptive than long filenames. See “stat: Displays Information About a File or Filesystem” on page 468 for a way to determine the maximum length of a filename on the local system.

Long filenames enable you to assign descriptive names to files. To help you select among files without typing entire filenames, shells support filename completion. For more information about this feature, see the “Filename completion” tip on page 224.

Case sensitivity

You can use uppercase and/or lowercase letters within filenames. Linux is case sensitive, so files named JANUARY, January, and january represent three distinct files.

Caution: Do not use SPACEs within filenames

Although Linux allows you to use SPACEs within filenames, it is a poor idea. Because a SPACE is a special character, you must quote it on a command line. Quoting a character on a command line can be difficult for a novice user and cumbersome for an experienced user. Use periods or underscores instead of SPACEs: joe.05.04.26, new_stuff.

If you are working with a filename that includes a SPACE, such as a file from another operating system, you must quote the SPACE on the command line by preceding it with a backslash or by placing quotation marks on either side of the filename. The two following commands send the file named my file to the printer.

$ lpr my\ file
$ lpr "my file"

Filename Extensions

A filename extension is the part of the filename that follows an embedded period. In the filenames listed in Table 6-1 on the next page, filename extensions help describe the contents of the file. Some programs, such as the C programming language compiler, default to specific filename extensions; in most cases, however, filename extensions are optional. Use extensions freely to make filenames easy to understand. If you like, you can use several periods within the same filename—for example, notes.4.10.54 or files.tar.gz.

Table 6-1 Filename extensions

Hidden Filenames

A filename that begins with a period is called a hidden filename (or a hidden file or sometimes an invisible file) because ls does not normally display it. The command ls –a displays all filenames, even hidden ones. Names of startup files (next) usually begin with a period so that they are hidden and do not clutter a directory listing. Two special hidden entries—single and double periods (. and ..)—appear in every directory (page 186).

Startup Files

Startup files, which appear in your home directory (page 143), give the shell and other programs information about you and your preferences. Frequently one of these files tells the shell what kind of terminal you are using (page 1153) and executes the stty (set terminal) utility to establish the erase (page 123) and line kill (page 123) keys.

Either you or the system administrator can put a shell startup file containing shell commands in your home directory. The shell executes the commands in this file each time you log in. Because the startup files have hidden filenames (filenames that begin with a period; above), you must use the ls –a command to see whether one is in your home directory. A GUI has many startup files. Usually you do not need to work with these files directly but can control startup sequences using icons on the desktop. See page 329 for more information about startup files.

Pathnames

Every file has a pathname, which is a trail from a directory through part of the directory hierarchy to an ordinary file or a directory. Within a pathname, a slash (/) following (to the right of) a filename indicates that the file is a directory file. The file following (to the right of) the slash can be an ordinary file or a directory file. The simplest pathname is a simple filename, which points to a file in the working directory (page 143). This section discusses absolute and relative pathnames and explains how to use each.

Absolute Pathnames

/ (root)

The root directory of the filesystem hierarchy does not have a name; it is referred to as the root directory and is represented by a slash (/) standing alone or at the left end of a pathname.

An absolute pathname starts with a slash (/), which represents the root directory. The slash is followed by the name of a file located in the root directory. An absolute pathname can continue, tracing a path through all intermediate directories, to the file identified by the pathname. String all the filenames in the path together, following each directory with a slash (/). This string of filenames is called an absolute pathname because it locates a file absolutely by tracing a path from the root directory to the file. Typically the absolute pathname of a directory does not include the trailing slash, although that format can be used to emphasize that the pathname specifies a directory (e.g., /home/zach/). The part of a pathname following the final slash is called a simple filename, filename, or basename. Figure 6-4 shows the absolute pathnames of directories and ordinary files in part of a filesystem hierarchy.

Figure 6-4 Absolute pathnames

Using an absolute pathname, you can list or otherwise work with any file on the local system, assuming you have permission to do so, regardless of the working directory at the time you give the command. For example, Sam can give the following command while working in his home directory to list the files in the /etc/ssh directory:

$ pwd
/home/sam
$ ls /etc/ssh
moduli ssh_host_dsa_key ssh_host_key.pub
ssh_config ssh_host_dsa_key.pub ssh_host_rsa_key
sshd_config ssh_host_key ssh_host_rsa_key.pub

~ (Tilde) in Pathnames

In another form of absolute pathname, the shell expands the characters ~/ (a tilde followed by a slash) at the start of a pathname into the pathname of your home directory. Using this shortcut, you can display your .bashrc startup file (page 331) with the following command no matter which directory is the working directory:

$ less ~/.bashrc

A tilde quickly references paths that start with your or someone else’s home directory. The shell expands a tilde followed by a username at the beginning of a pathname into the pathname of that user’s home directory. For example, assuming he has permission to do so, Max can examine Sam’s .bashrc file with the following command:

$ less ~sam/.bashrc

Refer to “Tilde Expansion” on page 407 for more information.

Relative Pathnames

A relative pathname traces a path from the working directory to a file. The pathname is relative to the working directory. Any pathname that does not begin with the root directory (represented by /) or a tilde (~) is a relative pathname. Like absolute pathnames, relative pathnames can trace a path through many directories. The simplest relative pathname is a simple filename, which identifies a file in the working directory. The examples in the next sections use absolute and relative pathnames.

Significance of the Working Directory

To access any file in the working directory, you need only a simple filename. To access a file in another directory, you must use a pathname. Typing a long pathname is tedious and increases the chance of making a mistake. This possibility is less likely under a GUI, where you click filenames or icons. You can choose a working directory for any particular task to reduce the need for long pathnames. Your choice of a working directory does not allow you to do anything you could not do otherwise—it just makes some operations easier.

Caution: When using a relative pathname, know which directory is the working directory

The location of the file you are accessing with a relative pathname is dependent on (is relative to) the working directory. Always make sure you know which directory is the working directory before you use a relative pathname. Use pwd to verify the directory. If you are creating a file using vim and you are not where you think you are in the file hierarchy, the new file will end up in an unexpected location.

It does not matter which directory is the working directory when you use an absolute pathname. Thus, the following command always edits a file named goals in your home directory:

$ vim ~/goals

Refer to Figure 6-5 as you read this paragraph. Files that are children of the working directory can be referenced by simple filenames. Grandchildren of the working directory can be referenced by short relative pathnames: two filenames separated by a slash. When you manipulate files in a large directory structure, using short relative pathnames can save you time and aggravation. If you choose a working directory that contains the files used most often for a particular task, you need use fewer long, cumbersome pathnames.

Figure 6-5 Relative pathnames

Working with Directories

This section discusses how to create directories (mkdir), switch between directories (cd), remove directories (rmdir), use pathnames to make your work easier, and move and copy files and directories between directories. It concludes with brief descriptions of important standard directories and files in the Linux filesystem.

mkdir: Creates a Directory

The mkdir utility creates a directory. The argument (page 1237) to mkdir is the pathname of the new directory. The following examples develop the directory structure shown in Figure 6-6. In the figure, the directories that are added appear in a lighter shade than the others and are connected by dashes.

Figure 6-6 The file structure developed in the examples

Following, pwd shows that Max is working in his home directory (/home/max), and ls shows the names of the files in his home directory: demo, names, and temp.

$ pwd
/home/max
$ ls
demo names temp
$ mkdir literature

Using mkdir, Max creates a directory named literature as a child of his home directory. He uses a relative pathname (a simple filename) because he wants the literature directory to be a child of the working directory. Max could have used an absolute pathname to create the same directory:mkdir /home/max/literature, mkdir ~max/literature, or mkdir ~/literature.

The following ls commands verify the presence of the new directory. The –F option to ls displays a slash after the name of each directory and an asterisk after each executable file (shell script, utility, or application). When you call it with an argument that is the name of a directory, ls lists the contents of that directory. The final ls displays nothing because there are no files in the literature directory.

$ ls
demo literature names temp
$ ls -F
demo literature/ names temp
$ ls literature
$

The following commands show two ways for Max to create the promo directory as a child of the newly created literature directory. The first way checks that /home/max is the working directory and uses a relative pathname:

$ pwd
/home/max
$ mkdir literature/promo

The second way uses an absolute pathname:

$ mkdir /home/max/literature/promo

Use the –p (parents) option to mkdir to create both the literature and promo directories with one command:

$ pwd
/home/max
$ ls
demo names temp
$ mkdir -p literature/promo

$ mkdir -p /home/max/literature/promo

cd: Changes to Another Working Directory

The cd (change directory) utility makes another directory the working directory; it does not change the contents of the working directory. The following examples show two ways to make the /home/max/literature directory the working directory, as verified by pwd. First Max uses cd with an absolute pathname to make literature his working directory—it does not matter which is the working directory when you give a command with an absolute pathname. A pwd command confirms the change Max made.

$ cd /home/max/literature
$ pwd
/home/max/literature

When used without an argument, cd makes your home directory the working directory, as it was when you logged in. The following cd command does not have an argument, so it makes Max’s home directory the working directory. Finally, knowing that he is working in his home directory, Max uses a simple filename to make the literature directory his working directory (cd literature) and confirms the change using pwd.

$ cd
$ pwd
/home/max
$ cd literature
$ pwd
/home/max/literature

The . and .. Directory Entries

The mkdir utility automatically puts two entries in each directory it creates: a single period (.) and a double period (..). The . is synonymous with the pathname of the working directory and can be used in its place; the .. is synonymous with the pathname of the parent of the working directory. These entries are hidden because their filenames begin with a period.

With the literature directory as the working directory, the following example uses .. three times: first to list the contents of the parent directory (/home/max), second to copy the memoA file to the parent directory, and third to list the contents of the parent directory again.

$ pwd
/home/max/literature
$ ls ..
demo literature names temp
$ cp memoA ..
$ ls ..
demo literature memoA names temp

After using cd to make promo (a subdirectory of literature) his working directory, Max can use a relative pathname to call vim to edit a file in his home directory.

$ cd promo
$ vim ../../names

You can use an absolute or relative pathname or a simple filename virtually anywhere a utility or program requires a filename or pathname. This usage holds true for ls, vim, mkdir, rm, and most other Linux utilities.

Tip: The working directory versus your home directory

The working directory is not the same as your home directory. Your home directory remains the same for the duration of your session and usually from session to session. Immediately after you log in, you are always working in the same directory: your home directory.

Unlike your home directory, the working directory can change as often as you like. You have no set working directory, which explains why some people refer to it as the current directory. When you log in and until you change directories using cd, your home directory is the working directory. If you were to change directories to Sam’s home directory, then Sam’s home directory would be the working directory.

rmdir: Deletes a Directory

The rmdir (remove directory) utility deletes a directory. You cannot delete the working directory or a directory that contains files other than the . and .. entries. If you need to delete a directory that has files in it, first use rm to delete the files and then delete the directory. You do not have to (nor can you) delete the . and .. entries; rmdir removes them automatically. The following command deletes the promo directory:

$ rmdir /home/max/literature/promo

The rm utility has a –r option (rm –r filename) that recursively deletes files, including directories, within a directory and also deletes the directory itself.

Caution: Use rm –r carefully, if at all

Although rm –r is a handy command, you must use it carefully. Do not use it with an ambiguous file reference such as *. It is frighteningly easy to wipe out your entire home directory with a single short command.

Using Pathnames

touch

Use a text editor to create a file named letter if you want to experiment with the examples that follow. Alternately you can use touch to create an empty file:

$ cd
$ pwd
/home/max
$ touch letter

With /home/max as the working directory, the following example uses cp with a relative pathname to copy the file letter to the /home/max/literature/promo directory. (You will need to create promo again if you deleted it earlier.) The copy of the file has the simple filename letter.0210:

$ cp letter literature/promo/letter.0210

If Max does not change to another directory, he can use vim as shown to edit the copy of the file he just made:

$ vim literature/promo/letter.0210

If Max does not want to use a long pathname to specify the file, he can use cd to make promo the working directory before using vim:

$ cd literature/promo
$ pwd
/home/max/literature/promo
$ vim letter.0210

To make the parent of the working directory (named /home/max/literature) the new working directory, Max can give the following command, which takes advantage of the .. directory entry:

$ cd ..
$ pwd
/home/max/literature

mv, cp: Move or Copy Files

Chapter 7 discusses the use of mv to rename files. However, mv works even more generally: You can use this utility to move files from one directory to another (change the pathname of a file) as well as to change a simple filename. When used to move one or more files to a new directory, themv command has this syntax:

mv existing-file-list directory

If the working directory is /home/max, Max can use the following command to move the files names and temp from the working directory to the literature directory:

$ mv names temp literature

This command changes the absolute pathnames of the names and temp files from /home/max/names and /home/max/temp to /home/max/literature/names and /home/max/literature/temp, respectively (Figure 6-7). Like most Linux commands, mv accepts either absolute or relative pathnames.

Figure 6-7 Using mv to move names and temp

As you work with Linux and create more files, you will need to create new directories using mkdir to keep the files organized. The mv utility is a useful tool for moving files from one directory to another as you extend your directory hierarchy.

The cp utility works in the same way mv does, except that it makes copies of the existing-file-list in the specified directory.

mv: Moves a Directory

Just as it moves ordinary files from one directory to another, so mv can move directories. The syntax is similar except you specify one or more directories, not ordinary files, to move:

mv existing-directory-list new-directory

If new-directory does not exist, the existing-directory-list must contain just one directory name, which mv changes to new-directory (mv renames the directory). Although you can rename directories using mv, you cannot copy their contents with cp unless you use the –r (recursive) option. Refer to the tar and cpio man pages for other ways to copy and move directories.

Important Standard Directories and Files

Originally files on a Linux system were not located in standard places within the directory hierarchy. The scattered files made it difficult to document and maintain a Linux system and just about impossible for someone to release a software package that would compile and run on all Linux systems. The first standard for the Linux filesystem, the FSSTND (Linux Filesystem Standard), was released early in 1994. In early 1995 work was started on a broader standard covering many UNIX-like systems: FHS (Linux Filesystem Hierarchy Standard; proton.pathname.com/fhs). More recently FHS has been incorporated in LSB (Linux Standard Base; www.linuxfoundation.org/collaborate/workgroups/lsb), a workgroup of FSG (Free Standards Group). Finally, FSG combined with OSDL (Open Source Development Labs) to form the Linux Foundation (www.linuxfoundation.org). Figure 6-8 shows the locations of some important directories and files as specified by FHS. The significance of many of these directories will become clear as you continue reading.

Figure 6-8 A typical FHS-based Linux filesystem structure

The following list describes the directories shown in Figure 6-8, some of the directories specified by FHS, and some other directories. Fedora/RHEL, however, does not use all the directories specified by FHS. Be aware that you cannot always determine the function of a directory by its name. For example, although /opt stores add-on software, /etc/opt stores configuration files for the software in /opt. See also “Important Files and Directories” on page 502.

/bin /usr/bin /sbin /usr/sbin

Recently, the files in /bin and /sbin were moved to /usr/bin and /usr/sbin, respectively, and /bin and /sbin were set up as symbolic links (page 206) to those directories:

$ ls -ld /bin /usr/bin /sbin /usr/sbin
lrwxrwxrwx. 1 root root 7 07-16 18:37 /bin -> usr/bin
lrwxrwxrwx. 1 root root 8 07-16 18:37 /sbin -> usr/sbin
dr-xr-xr-x. 2 root root 53248 07-27 15:36 /usr/bin
dr-xr-xr-x. 2 root root 20480 07-27 15:36 /usr/sbin

See fedoraproject.org/wiki/Features/UsrMove for more information.

Root The root directory, present in all Linux filesystem structures, is the ancestor of all files in the filesystem. It does not have a name and is represented by a slash (/) standing alone or at the left end of a pathname.

/bin

A link to /usr/bin.

/boot

Static files of the boot loader Contains all of the files needed to boot the system.

/dev

Device files Contains all files that represent peripheral devices, such as disk drives, terminals, and printers. Previously this directory was filled with all possible devices. The udev utility (page 516) provides a dynamic device directory that enables /dev to contain only devices that are present on the system. See also /dev on page 503.

/etc

Machine–local system configuration files Holds administrative, configuration, and other system files.

/etc/opt

Configuration files for add-on software packages kept in /opt

/etc/X11

Machine–local configuration files for the X Window System

/home

User home directories Each user’s home directory is typically one of many subdirectories of the /home directory. As an example, assuming that users’ directories are under /home, the absolute pathname of Zach’s home directory is /home/zach. On some systems the users’ directories might not be found under /home but instead might be spread among other directories such as /inhouse and /clients.

/lib

A link to /usr/lib.

/lib64

A link to /usr/lib64.

/lib/modules

Loadable kernel modules

/mnt

Mount point for temporarily mounting filesystems

/opt

Add-on (optional) software packages

/proc

Kernel and process information virtual filesystem

/root

Home directory for the root account

/run

Runtime (volatile) data A tmpfs filesystem (mounted, but stored in RAM) that holds startup files previously hidden in /dev and other directories. For more information see lists.fedoraproject.org/pipermail/devel/2011-March/150031.html.

/sbin

A link to /usr/sbin.

/sys

Device pseudofilesystem See udev on page 516 for more information.

/tmp

Temporary files

/usr

Installed system Includes subdirectories that contain information used by the system. Files in subdirectories do not change often and can be shared by several systems.

/usr/bin

Most user commands Contains the standard Linux utility programs.

/usr/sbin

Essential system binaries Utilities used for system administration.

/usr/games

Games and educational programs

/usr/include

Header files included by C programs

/usr/lib

Shared libraries (32-bit)

/usr/lib64

Shared libraries (64-bit)

/usr/local

Local hierarchy Holds locally important files and directories that are added to the system. Subdirectories can include bin, games, include, lib, sbin, share, and src.

/usr/sbin

Nonvital system administration binaries See /sbin.

/usr/share

Architecture-independent data Subdirectories can include dict, doc, games, info, locale, man, misc, terminfo, and zoneinfo.

/usr/share/doc

Documentation

/usr/share/info

GNU info system’s primary directory

/usr/share/man

Online manuals

/usr/src

Source code

/var

Variable data Files with contents that vary as the system runs are kept in subdirectories under /var. The most common examples are temporary files, system log files, spooled files, and user mailbox files. Subdirectories can include cache, lib, lock, log, mail, opt, run, spool, tmp, and yp.

/var/log

Log files Contains lastlog (a record of the last login by each user), messages (system messages from syslogd), and wtmp (a record of all logins/logouts), among other log files.

/var/spool

Spooled application data Contains anacron, at, cron, lpd, mail, mqueue, samba, and other directories. The file /var/mail is typically a link to /var/spool/mail.

Access Permissions

In addition to the controls imposed by SELinux (page 472), Fedora/RHEL supports two methods of controlling who can access a file and how they can access it: traditional Linux access permissions and ACLs (Access Control Lists). This section describes traditional Linux access permissions. See page 198 for a discussion of ACLs, which provide finer-grained control of access permissions than do traditional access permissions.

Three types of users can access a file: the owner of the file (owner), a member of a group that the file is associated with (group; see page 506 for more information on groups), and everyone else (other). A user can attempt to access an ordinary file in three ways: by trying to read from, write to, or execute it.

ls –l: Displays Permissions

When you call ls with the –l option and the name of one or more ordinary files, ls displays a line of information about the file(s). See “ls output” on page 28 for information about the format of the display this book uses. The following example displays information for two files. The fileletter.0210 contains the text of a letter, and check_spell contains a shell script, a program written in a high-level shell programming language:

$ ls -l check_spell letter.0210
-rwxr-xr-x. 1 sam pubs 766 03-21 14:02 check_spell
-rw-r--r--. 1 sam pubs 6193 02-10 14:22 letter.0210

From left to right, the lines that an ls –l command displays contain the following information (refer to Figure 6-9):

• The type of file (first character)

• The file’s access permissions (the next nine characters)

• The ACL flag (present if the file has an ACL, page 198)

• The number of links to the file (page 203)

• The name of the owner of the file (usually the person who created the file)

• The name of the group the file is associated with

• The size of the file in characters (bytes)

• The date and time the file was created or last modified

• The name of the file

Figure 6-9 The columns displayed by the ls –l command

The type of file (first column) for letter.0210 is a hyphen (–) because it is an ordinary file (directory files have a d in this column).

The next three characters specify the access permissions for the owner of the file: r indicates read permission, w indicates write permission, and x indicates execute permission. A – in a column indicates that the owner does not have the permission that could have appeared in that position.

In a similar manner the next three characters represent permissions for the group, and the final three characters represent permissions for other (everyone else). In the preceding example, the owner of letter.0210 can read from and write to the file, whereas the group and others can only read from the file, and no one is allowed to execute it. Although execute permission can be allowed for any file, it does not make sense to assign execute permission to a file that contains a document such as a letter. The check_spell file is an executable shell script, so execute permission is appropriate for it. (The owner, group, and others have execute permission.)

chmod: Changes File Access Permissions

The Linux file access permission scheme lets you give other users access to the files you want to share while keeping your private files confidential. You can allow other users to read from and write to a file (handy if you are one of several people working on a joint project). You can allow others only to read from a file (perhaps a project specification you are proposing). Or you can allow others only to write to a file (similar to an inbox or mailbox, where you want others to be able to send you mail but do not want them to read your mail). Similarly you can protect entire directories from being scanned (covered shortly).

Security: A user with root privileges can access any file on the system

There is an exception to the access permissions described in this section. Anyone who can gain root privileges has full access to all files, regardless of the file’s owner or access permissions. Of course, if the file is encrypted, read access does not mean the person reading the file can understand what is in the file.

The owner of a file controls which users have permission to access the file and how those users can access it. When you own a file, you can use the chmod (change mode) utility to change access permissions for that file. You can specify symbolic (relative) or numeric (absolute) arguments tochmod.

Symbolic Arguments to chmod

The following example, which uses symbolic arguments to chmod, adds (+) read and write permissions (rw) for all (a) users:

$ ls -l letter.0210
-rw-r-----. 1 sam pubs 6193 02-10 14:22 letter.0210
$ chmod a+rw letter.0210
$ ls -l letter.0210
-rw-rw-rw-. 1 sam pubs 6193 02-10 14:22 letter.0210

Tip: You must have read permission to execute a shell script

Because a shell needs to read a shell script (a text file containing shell commands) before it can execute the commands within that script, you must have read permission for the file containing the script to execute it. You also need execute permission to execute a shell script directly from the command line. In contrast, binary (program) files do not need to be read; they are executed directly. You need only execute permission to run a binary program.

Using symbolic arguments with chmod modifies existing permissions; the change a given argument makes depends on (is relative to) the existing permissions. In the next example, chmod removes (–) read (r) and execute (x) permissions for other (o) users. The owner and group permissions are not affected.

$ ls -l check_spell
-rwxr-xr-x. 1 sam pubs 766 03-21 14:02 check_spell
$ chmod o-rx check_spell
$ ls -l check_spell
-rwxr-x---. 1 sam pubs 766 03-21 14:02 check_spell

In addition to a (all) and o (other), you can use g (group) and u (user, although user refers to the owner of the file who might or might not be the user of the file at any given time) in the argument to chmod. For example, chmod a+x adds execute permission for all users (other, group, and owner), and chmod go–rwx removes all permissions for all but the owner of the file.

Tip: chmod: o for other, u for owner

When using chmod, many people assume that the o stands for owner; it does not. The o stands for other, whereas u stands for owner (user). The acronym UGO (user-group-other) might help you remember how permissions are named.

Numeric Arguments to chmod

You can also use numeric arguments to specify permissions with chmod. In place of the letters and symbols specifying permissions used in the previous examples, numeric arguments comprise three octal digits. (A fourth, leading digit controls setuid and setgid permissions and is discussed next.) The first digit specifies permissions for the owner, the second for the group, and the third for other users. A 1 gives the specified user(s) execute permission, a 2 gives write permission, and a 4 gives read permission. Construct the digit representing the permissions for the owner, group, or others by ORing (adding) the appropriate values as shown in the following examples. Using numeric arguments sets file permissions absolutely; it does not modify existing permissions as symbolic arguments do.

In the following example, chmod changes permissions so only the owner of the file can read from and write to the file, regardless of how permissions were previously set. The 6 in the first position gives the owner read (4) and write (2) permissions. The 0s remove all permissions for the group and other users.

$ chmod 600 letter.0210
$ ls -l letter.0210
-rw-------. 1 sam pubs 6193 02-10 14:22 letter.0210

Next, 7 (4 + 2 + 1) gives the owner read, write, and execute permissions. The 5 (4 + 1) gives the group and other users read and execute permissions:

$ chmod 755 check_spell
$ ls -l check_spell
-rwxr-xr-x. 1 sam pubs 766 03-21 14:02 check_spell

Refer to Table 6-2 for more examples of numeric permissions.

Table 6-2 Examples of numeric permission specifications

Refer to page 337 for more information on using chmod to make a file executable and refer to the chmod man page for more information on absolute arguments and chmod in general. Refer to page 506 for more information on groups.

chown: Changes File Ownership

The chown utility changes the owner of one or more files specified as arguments. Only a user working with root privileges can change the ownership of a file. In the following example, a user working with root privileges changes the owner of the memo file from Sam to Max, displaying the name of the owner before and after the change.

$ ls -l memo
-rw-rw-r--. 1 sam pubs 3933 04-30 17:26 memo
$ su -c 'chown max memo'
Password:
$ ls -l memo
-rw-rw-r--. 1 max pubs 3933 04-30 17:26 memo

The –R (––recursive) option allows you to specify a directory as an argument; it changes the ownership of all files in the specified directory hierarchy. The –v (––verbose) option displays a message for each file chown processes, saying whether its owner was retained or changed.

chgrp: Changes File Group Association

The chgrp utility changes the group associated with of one or more files specified as arguments. Only the owner of a file or a user working with root privileges can change the group associated with a file. In the following example, Max, who owns the file named memo, changes the group associated with memo from pubs to max, displaying the name of the group before and after the change.

$ ls -l memo
-rw-rw-r--. 1 max pubs 3933 04-30 17:26 memo
$ chgrp max memo
$ ls -l memo
-rw-rw-r--. 1 max max 3933 04-30 17:26 memo

The –R (––recursive) option allows you to specify a directory as an argument; it changes the group associated with of all files in the specified directory hierarchy. The –v (––verbose) option displays a message for each file chgrp processes, saying whether its group was retained or changed.

Setuid and Setgid Permissions

When you execute a file that has setuid (set user ID) permission, the process executing the file takes on the privileges of the file’s owner. For example, if you run a setuid program that removes all files in a directory, you can remove files in any of the file owner’s directories, even if you do not normally have permission to do so. In a similar manner, setgid (set group ID) permission gives the process executing the file the privileges of the group the file is associated with.

Security: Minimize use of setuid and setgid programs owned by root

Executable files that are setuid and owned by root have root privileges when they run, even if they are not run by root. This type of program is very powerful because it can do anything that root can do (and that the program is designed to do). Similarly executable files that are setgid and belong to the group root have extensive privileges.

Because of the power they hold and their potential for destruction, it is wise to avoid indiscriminately creating and using setuid programs owned by root and setgid programs belonging to the group root. Because of their inherent dangers, many sites minimize the use of these programs on their systems. One necessary setuid program is passwd. See page 425 for a tip on setuid files owned by root and page 458 for a command that lists setuid files on the local system.

Because of this danger, Fedora/RHEL has removed most setuid files. For more information see fedoraproject.org/wiki/Features/RemoveSETUID.

The following example shows a user working with root privileges and using symbolic arguments to chmod to give one program setuid privileges and another program setgid privileges. The ls –l output (page 191) shows setuid permission by displaying an s in the owner’s executable position and setgid permission by displaying an s in the group’s executable position:

# ls -l myprog*
-rwxr-xr-x. 1 root pubs 362804 03-21 15:38 myprog1
-rwxr-xr-x. 1 root pubs 189960 03-21 15:38 myprog2

# chmod u+s myprog1
# chmod g+s myprog2

# ls -l myprog*
-rwsr-xr-x. 1 root pubs 362804 03-21 15:38 myprog1
-rwxr-sr-x. 1 root pubs 189960 03-21 15:38 myprog2

Sticky bit

The next example uses numeric arguments to chmod to make the same changes. When you use four digits to specify permissions, setting the first digit to 1 sets the sticky bit (page 1275), setting it to 2 specifies setgid permissions, and setting it to 4 specifies setuid permissions:

# ls -l myprog*
-rwxr-xr-x. 1 root pubs 362804 03-21 15:38 myprog1
-rwxr-xr-x. 1 root pubs 189960 03-21 15:38 myprog2

# chmod 4755 myprog1
# chmod 2755 myprog2

# ls -l myprog*
-rwsr-xr-x. 1 root pubs 362804 03-21 15:38 myprog1
-rwxr-sr-x. 1 root pubs 189960 03-21 15:38 myprog2

Security: Do not write setuid shell scripts

Never give shell scripts setuid permission. Several techniques for subverting them are well known.

Directory Access Permissions

Access permissions have slightly different meanings when they are applied to directories. Although the three types of users can read from or write to a directory, the directory cannot be executed. Execute permission is redefined for a directory: It means that you can cd into the directory and/or examine files that you have permission to read from in the directory. It has nothing to do with executing a file.

When you have only execute permission for a directory, you can use ls to list a file in the directory if you know its name. You cannot use ls to list the entire contents of the directory. In the following exchange, Zach first verifies that he is logged in as himself. He then checks the permissions on Max’s info directory. You can view the access permissions associated with a directory by running ls with the –d (directory) and –l (long) options:

$ who am i
zach pts/7 Aug 21 10:02
$ ls -ld /home/max/info
drwx-----x. 2 max pubs 4096 08-21 09:31 /home/max/info
$ ls -l /home/max/info
ls: /home/max/info: Permission denied

The d at the left end of the line that ls displays indicates /home/max/info is a directory. Max has read, write, and execute permissions; members of the pubs group have no access permissions; and other users have execute permission only, indicated by the x at the right end of the permissions. Because Zach does not have read permission for the directory, the ls –l command returns an error.

When Zach specifies the names of the files he wants information about, he is not reading new directory information but rather searching for specific information, which he is allowed to do with execute access to the directory. He has read permission for notes so he has no problem using cat to display the file. He cannot display financial because he does not have read permission for it:

$ ls -l /home/max/info/financial /home/max/info/notes
-rw-------. 1 max pubs 34 08-21 09:31 /home/max/info/financial
-rw-r--r--. 1 max pubs 30 08-21 09:32 /home/max/info/notes
$ cat /home/max/info/notes
This is the file named notes.
$ cat /home/max/info/financial
cat: /home/max/info/financial: Permission denied

Next Max gives others read access to his info directory:

$ chmod o+r /home/max/info

When Zach checks his access permissions on info, he finds he has both read and execute access to the directory. Now ls –l displays the contents of the info directory, but he still cannot read financial. (This restriction is an issue of file permissions, not directory permissions.) Finally, Zach tries to create a file named newfile using touch. If Max were to give him write permission to the info directory, Zach would be able to create new files in it:

$ ls -ld /home/max/info
drwx---r-x. 2 max pubs 4096 08-21 09:31 /home/max/info
$ ls -l /home/max/info
total 8
-rw-------. 1 max pubs 34 08-21 09:31 financial
-rw-r--r--. 1 max pubs 30 08-21 09:32 notes
$ cat /home/max/info/financial
cat: financial: Permission denied
$ touch /home/max/info/newfile
touch: cannot touch '/home/max/info/newfile': Permission denied

ACLs: Access Control Lists

ACLs (Access Control Lists) provide finer-grained control over which users can access specific directories and files than do traditional Linux permissions (page 191). Using ACLs you can specify the ways in which each of several users can access a directory or file. Because ACLs can reduce performance, do not enable them on filesystems that hold system files, where the traditional Linux permissions are sufficient. Also, be careful when moving, copying, or archiving files: Not all utilities preserve ACLs. In addition, you cannot copy ACLs to filesystems that do not support ACLs.

An ACL comprises a set of rules. A rule specifies how a specific user or group can access the file that the ACL is associated with. There are two kinds of rules: access rules and default rules. (The documentation refers to access ACLs and default ACLs, even though there is only one type of ACL: There is one type of list [ACL] and there are two types of rules that an ACL can contain.)

An access rule specifies access information for a single file or directory. A default ACL pertains to a directory only; it specifies default access information (an ACL) for any file in the directory that is not given an explicit ACL.

Caution: Most utilities do not preserve ACLs

When used with the –p (preserve) or –a (archive) option, cp preserves ACLs when it copies files. The mv utility also preserves ACLs. When you use cp with the –p or –a option and it is not able to copy ACLs, and in the case where mv is unable to preserve ACLs, the utility performs the operation and issues an error message:

$ mv report /tmp
mv: preserving permissions for '/tmp/report': Operation not supported

Other utilities, such as tar, cpio, and dump, do not support ACLs. You can use cp with the –a option to copy directory hierarchies, including ACLs.

You can never copy ACLs to a filesystem that does not support ACLs or to a filesystem that does not have ACL support turned on.

Enabling ACLs

The acl package must be installed before you can use ACLs. Fedora/RHEL officially supports ACLs on ext2, ext3, and ext4 filesystems only, although informal support for ACLs is available on other filesystems. To use ACLs on an ext2/ext3/ext4 filesystem, you must mount the device with the acl option (no_acl is the default). For example, if you want to mount the device represented by /home so that you can use ACLs on files in /home, you can add acl to its options list in /etc/fstab:

$ grep home /etc/fstab
LABEL=/home /home ext4 defaults,acl 1 2

remount option

After changing fstab, you need to remount /home before you can use ACLs. If no one else is using the system, you can unmount it and mount it again (working with root privileges) as long as the working directory is not in the /home hierarchy. Alternately you can use the remount option tomount to remount /home while the device is in use:

# mount -v -o remount /home
/dev/sda3 on /home type ext4 (rw,acl)

See page 524 for information on fstab and page 520 for information on mount.

Working with Access Rules

The setfacl utility modifies a file’s ACL and getfacl displays a file’s ACL. When you use getfacl to obtain information about a file that does not have an ACL, it displays some of the same information as an ls –l command, albeit in a different format:

$ ls -l report
-rw-r--r--. 1 max pubs 9537 01-12 23:17 report

$ getfacl report
# file: report
# owner: max
# group: pubs
user::rw-
group::r--
other::r--

The first three lines of the getfacl output compose the header; they specify the name of the file, the owner of the file, and the group the file is associated with. For more information refer to “ls –l: Displays Permissions” on page 191. The ––omit-header (or just ––omit) option causes getfaclnot to display the header:

$ getfacl --omit-header report
user::rw-
group::r--
other::r--

In the line that starts with user, the two colons (::) with no name between them indicate that the line specifies the permissions for the owner of the file. Similarly, the two colons in the group line indicate that the line specifies permissions for the group the file is associated with. The two colons following other are there for consistency: No name can be associated with other.

The setfacl ––modify (or –m) option adds or modifies one or more rules in a file’s ACL using the following format:

setfacl ––modify ugo:name:permissions file-list

where ugo can be either u, g, or o to indicate that the command sets file permissions for a user, a group, or all other users, respectively; name is the name of the user or group that permissions are being set for; permissions is the permissions in either symbolic or absolute format; and file-list is the list of files the permissions are to be applied to. You must omit name when you specify permissions for other users (o). Symbolic permissions use letters to represent file permissions (rwx, r–x, and so on), whereas absolute permissions use an octal number. While chmod uses three sets of permissions or three octal numbers (one each for the owner, group, and other users), setfacl uses a single set of permissions or a single octal number to represent the permissions being granted to the user or group represented by ugo and name. See the discussion of chmod on page 193 for more information about symbolic and absolute representations of file permissions.

For example, both of the following commands add a rule to the ACL for the report file that gives Sam read and write permission to that file:

$ setfacl --modify u:sam:rw- report

$ setfacl --modify u:sam:6 report

$ getfacl report
# file: report
# owner: max
# group: pubs
user::rw-
user:sam:rw-
group::r--
mask::rw-
other::r--

The line containing user:sam:rw– shows that the user named sam has read and write access (rw–) to the file. See page 191 for an explanation of how to read access permissions. See the following optional section for a description of the line that starts with mask.

When a file has an ACL, ls –l displays a plus sign (+) following the permissions, even if the ACL is empty:

$ ls -l report
-rw-rw-r--+ 1 max pubs 9537 01-12 23:17 report

Optional: Effective Rights Mask

The line in the output of getfacl that starts with mask specifies the effective rights mask. This mask limits the effective permissions granted to ACL groups and users. It does not affect the owner of the file or the group the file is associated with. In other words, it does not affect traditional Linux permissions. However, because setfacl always sets the effective rights mask to the least restrictive ACL permissions for the file, the mask has no effect unless you set it explicitly after you set up an ACL for the file. You can set the mask by specifyingmask in place of ugo and by not specifying a name in a setfacl command.

The following example sets the effective rights mask to read for the report file:

$ setfacl -m mask::r-- report

The mask line in the following getfacl output shows the effective rights mask set to read (r––). The line that displays Sam’s file access permissions shows them still set to read and write. However, the comment at the right end of the line shows that his effective permission is read.

$ getfacl report
# file: report
# owner: max
# group: pubs
user::rw-
user:sam:rw- #effective:r--
group::r--
mask::r--
other::r--

As the next example shows, setfacl can modify ACL rules and can set more than one ACL rule at a time:

$ setfacl -m u:sam:r--,u:zach:rw- report

$ getfacl --omit-header report
user::rw-
user:sam:r--
user:zach:rw-
group::r--
mask::rw-
other::r--

The –x option removes ACL rules for a user or a group. It has no effect on permissions for the owner of the file or the group that the file is associated with. The next example shows setfacl removing the rule that gives Sam permission to access the file:

$ setfacl -x u:sam report

$ getfacl --omit-header report
user::rw-
user:zach:rw-
group::r--
mask::rw-
other::r--

You must not specify permissions when you use the –x option. Instead, specify only the ugo and name. The –b option, followed by a filename only, removes all ACL rules and the ACL itself from the file or directory you specify.

Both setfacl and getfacl have many options. Use the ––help option to display brief lists of options or refer to the man pages for details.

Setting Default Rules for a Directory

The following example shows that the dir directory initially has no ACL. The setfacl command uses the –d (default) option to add two default rules to the ACL for dir. These rules apply to all files in the dir directory that do not have explicit ACLs. The rules give members of the pubs group read and execute permissions and give members of the adm group read, write, and execute permissions.

$ ls -ld dir
drwx------. 2 max pubs 4096 02-12 23:15 dir
$ getfacl dir
# file: dir
# owner: max
# group: pubs
user::rwx
group::---
other::---

$ setfacl -d -m g:pubs:r-x,g:adm:rwx dir

The following ls command shows that the dir directory now has an ACL, as indicated by the + to the right of the permissions. Each of the default rules that getfacl displays starts with default:. The first two default rules and the last default rule specify the permissions for the owner of the file, the group that the file is associated with, and all other users. These three rules specify the traditional Linux permissions and take precedence over other ACL rules. The third and fourth rules specify the permissions for the pubs and adm groups. Next is the default effective rights mask.

$ ls -ld dir
drwx------+ 2 max pubs 4096 02-12 23:15 dir
$ getfacl dir
# file: dir
# owner: max
# group: pubs
user::rwx
group::---
other::---
default:user::rwx
default:group::---
default:group:pubs:r-x
default:group:adm:rwx
default:mask::rwx
default:other::---

Remember that the default rules pertain to files held in the directory that are not assigned ACLs explicitly. You can also specify access rules for the directory itself.

When you create a file within a directory that has default rules in its ACL, the effective rights mask for that file is created based on the file’s permissions. In some cases the mask can override default ACL rules.

In the next example, touch creates a file named new in the dir directory. The ls command shows this file has an ACL. Based on the value of umask (page 469), both the owner and the group that the file is associated with have read and write permissions for the file. The effective rights mask is set to read and write so that the effective permission for pubs is read and the effective permissions for adm are read and write. Neither group has execute permission.

$ cd dir
$ touch new
$ ls -l new
-rw-rw----+ 1 max pubs 0 02-13 00:39 new
$ getfacl --omit new
user::rw-
group::---
group:pubs:r-x #effective:r--
group:adm:rwx #effective:rw-
mask::rw-
other::---

If you change the file’s traditional permissions to read, write, and execute for the owner and the group, the effective rights mask changes to read, write, and execute, and the groups specified by the default rules gain execute access to the file.

$ chmod 770 new
$ ls -l new
-rwxrwx---+ 1 max pubs 0 02-13 00:39 new
$ getfacl --omit new
user::rwx
group::---
group:pubs:r-x
group:adm:rwx
mask::rwx
other::---

Links

A link is a pointer to a file. Each time you create a file using vim, touch, cp, or some other means, you are putting a pointer in a directory. This pointer associates a filename with a place on the disk. When you specify a filename in a command, you are indirectly pointing to the place on the disk that holds the information you want.

Sharing files can be useful when two or more people are working on the same project and need to share some information. You can make it easy for other users to access one of your files by creating additional links to the file.

To share a file with another user, first give the user permission to read from and write to the file (page 193). You might also have to change the access permissions of the parent directory of the file to give the user read, write, or execute permission (page 197). When the permissions are appropriately set, the user can create a link to the file so each of you can access the file from your separate directory hierarchies.

A link can also be useful to a single user with a large directory hierarchy. You can create links to cross-classify files in your directory hierarchy, using different classifications for different tasks. For example, if you have the file layout depicted in Figure 6-2 on page 177, a file named to_domight appear in each subdirectory of the correspond directory—that is, in personal, memos, and business. If you find it difficult to keep track of everything you need to do, you can create a separate directory named to_do in the correspond directory. You can then link each subdirectory’s to-do list into that directory. For example, you could link the file named to_do in the memos directory to a file named memos in the to_do directory. This set of links is shown in Figure 6-10.

Figure 6-10 Using links to cross-classify files

Although it might sound complicated, this technique keeps all your to-do lists conveniently in one place. The appropriate list is easily accessible in the task-related directory when you are busy composing letters, writing memos, or handling personal business.

Tip: About the discussion of hard links

Two kinds of links exist: hard links and symbolic (soft) links. Hard links are older and becoming outdated. The section on hard links is marked as optional; you can skip it, although it discusses inodes and gives you insight into the structure of the filesystem.

Optional

Hard Links

A hard link to a file appears as another file. If the file appears in the same directory as the linked-to file, the links must have different filenames because two files in the same directory cannot have the same name. You can create a hard link to a file only from within the filesystem that holds the file.

ln: Creates a Hard Link

The ln (link) utility (without the –s or ––symbolic option) creates a hard link to an existing file using the following syntax:

ln existing-file new-link

The next command shows Zach making the link shown in Figure 6-11 by creating a new link named /home/max/letter to an existing file named draft in Zach’s home directory:

$ pwd
/home/zach
$ ln draft /home/max/letter

Figure 6-11 Two links to the same file: /home/max/letter and /home/zach/draft

The new link appears in the /home/max directory with the filename letter. In practice, Max might need to change directory permissions so Zach will be able to create the link. Even though /home/max/letter appears in Max’s directory, Zach is the owner of the file because he created it.

The ln utility creates an additional pointer to an existing file, but it does not make another copy of the file. Because there is only one file, the file status information—such as access permissions, owner, and the time the file was last modified—is the same for all links; only the filenames differ. When Zach modifies /home/zach/draft, for example, Max sees the changes in /home/max/letter.

cp Versus ln

The following commands verify that ln does not make an additional copy of a file. Create a file, use ln to make an additional link to the file, change the contents of the file through one link, and verify the change through the other link:

$ cat file_a
This is file A.
$ ln file_a file_b
$ cat file_b
This is file A.
$ vim file_b
...
$ cat file_b
This is file B after the change.
$ cat file_a
This is file B after the change.

If you try the same experiment using cp instead of ln and change a copy of the file, the difference between the two utilities will become clearer. After you change a copy of a file, the two files are different:

$ cat file_c
This is file C.
$ cp file_c file_d
$ cat file_d
This is file C.
$ vim file_d
...
$ cat file_d
This is file D after the change.
$ cat file_c
This is file C.

ls and link counts

You can use ls with the –l option, followed by the names of the files you want to compare, to confirm that the status information is the same for two links to the same file and is different for files that are not linked. In the following example, the 2 in the links field (just to the left of max) shows there are two links to file_a and file_b (from the previous example):

$ ls -l file_a file_b file_c file_d
-rw-r--r--. 2 max pubs 33 05-24 10:52 file_a
-rw-r--r--. 2 max pubs 33 05-24 10:52 file_b
-rw-r--r--. 1 max pubs 16 05-24 10:55 file_c
-rw-r--r--. 1 max pubs 33 05-24 10:57 file_d

Although it is easy to guess which files are linked to one another in this example, ls does not explicitly tell you.

ls and inodes

Use ls with the –i option to determine without a doubt which files are linked. The –i option lists the inode (page 1254) number for each file. An inode is the control structure for a file. If the two filenames have the same inode number, they share the same control structure and are links to the same file. Conversely, when two filenames have different inode numbers, they are different files. The following example shows that file_a and file_b have the same inode number and that file_c and file_d have different inode numbers:

$ ls -i file_a file_b file_c file_d
3534 file_a 3534 file_b 5800 file_c 7328 file_d

All links to a file are of equal value: The operating system cannot distinguish the order in which multiple links were created. When a file has two links, you can remove either one and still access the file through the remaining link. You can remove the link used to create the file, for example, and as long as one link remains, still access the file through that link.

Symbolic Links

In addition to hard links, Linux supports symbolic links, also called soft links or symlinks. A hard link is a pointer to a file (the directory entry points to the inode), whereas a symbolic link is an indirect pointer to a file (the directory entry contains the pathname of the pointed-to file—a pointer to the hard link to the file).

Advantages of symbolic links

Symbolic links were developed because of the limitations inherent in hard links. You cannot create a hard link to a directory, but you can create a symbolic link to a directory.

In many cases the Linux file hierarchy encompasses several filesystems. Because each filesystem keeps separate control information (i.e., separate inode tables or filesystem structures) for the files it holds, it is not possible to create hard links between files in different filesystems. A symbolic link can point to any file, regardless of where it is located in the file structure, but a hard link to a file must be in the same filesystem as the other hard link(s) to the file. When you create links only among files in your home directory, you will not notice this limitation.

A major advantage of a symbolic link is that it can point to a nonexistent file. This ability is useful if you need a link to a file that is periodically removed and re-created. A hard link keeps pointing to a “removed” file, which the link keeps alive even after a new file is created. In contrast, a symbolic link always points to the newly created file and does not interfere when you delete the old file. For example, a symbolic link could point to a file that gets checked in and out under a source code control system, a .o file that is re-created by the C compiler each time you run make, or a log file that is repeatedly archived.

Although they are more general than hard links, symbolic links have some disadvantages. Whereas all hard links to a file have equal status, symbolic links do not have the same status as hard links. When a file has multiple hard links, it is analogous to a person having multiple full legal names, as many married women do. In contrast, symbolic links are analogous to nicknames. Anyone can have one or more nicknames, but these nicknames have a lesser status than legal names. The following sections describe some of the peculiarities of symbolic links.

ln: Creates Symbolic Links

The ln utility with the ––symbolic (or –s) option creates a symbolic link. The following example creates a symbolic link /tmp/s3 to the file sum in Max’s home directory. When you use an ls –l command to look at the symbolic link, ls displays the name of the link and the name of the file it points to. The first character of the listing is l (for link).

$ ln --symbolic /home/max/sum /tmp/s3
$ ls -l /home/max/sum /tmp/s3
-rw-rw-r--. 1 max pubs 38 06-12 09:51 /home/max/sum
lrwxrwxrwx. 1 max pubs 14 06-12 09:52 /tmp/s3 -> /home/max/sum
$ cat /tmp/s3
This is sum.

The sizes and times of the last modifications of the two files are different. Unlike a hard link, a symbolic link to a file does not have the same status information as the file itself.

You can also use ln to create a symbolic link to a directory. When you use the ––symbolic option, ln works as expected whether the file you are creating a link to is an ordinary file or a directory.

Caution: Use absolute pathnames with symbolic links

Symbolic links are literal and are not aware of directories. A link that points to a relative pathname, which includes simple filenames, assumes the relative pathname is relative to the directory that the link was created in (not the directory the link was created from). In the following example, the link points to the file named sum in the /tmp directory. Because no such file exists, cat gives an error message:

$ pwd
/home/max
$ ln --symbolic sum /tmp/s4
$ ls -l sum /tmp/s4
lrwxrwxrwx. 1 max pubs 3 06-12 10:13 /tmp/s4 -> sum
-rw-rw-r--. 1 max pubs 38 06-12 09:51 sum
$ cat /tmp/s4
cat: /tmp/s4: No such file or directory

Optional: cd and Symbolic Links

When you use a symbolic link as an argument to cd to change directories, the results can be confusing, particularly if you did not realize that you were using a symbolic link.

If you use cd to change to a directory that is represented by a symbolic link, the pwd shell builtin (page 170) lists the name of the symbolic link. The pwd utility (/bin/pwd) lists the name of the linked-to directory, not the link, regardless of how you got there.

$ ln -s /home/max/grades /tmp/grades.old
$ pwd
/home/max
$ cd /tmp/grades.old
$ pwd
/tmp/grades.old
$ /bin/pwd
/home/max/grades

When you change directories back to the parent, you end up in the directory holding the symbolic link:

$ cd ..
$ pwd
/tmp
$ /bin/pwd
/tmp

rm: Removes a Link

When you create a file, there is one hard link to it. You can then delete the file or, using Linux terminology, remove the link with the rm utility. When you remove the last hard link to a file, you can no longer access the information stored there, and the operating system releases the space the file occupied on the disk for use by other files. This space is released even if symbolic links to the file remain. When there is more than one hard link to a file, you can remove a hard link and still access the file from any remaining link. Unlike DOS and Windows, Linux does not provide an easy way to undelete a file once you have removed it. A skilled hacker, however, can sometimes piece the file together with time and effort.

When you remove all hard links to a file, you will not be able to access the file through a symbolic link. In the following example, cat reports that the file total does not exist because it is a symbolic link to a file that has been removed:

$ ls -l sum
-rw-r--r--. 1 max pubs 981 05-24 11:05 sum
$ ln -s sum total
$ rm sum
$ cat total
cat: total: No such file or directory
$ ls -l total
lrwxrwxrwx. 1 max pubs 6 05-24 11:09 total -> sum

When you remove a file, be sure to remove all symbolic links to it. Remove a symbolic link in the same way you remove other files:

$ rm total

Chapter Summary

Linux has a hierarchical, or treelike, file structure that makes it possible to organize files so you can find them quickly and easily. The file structure contains directory files and ordinary files. Directories contain other files, including other directories; ordinary files generally contain text, programs, or images. The ancestor of all files is the root directory and is represented by / standing alone or at the left end of a pathname.

Most Linux filesystems support 255-character filenames. Nonetheless, it is a good idea to keep filenames simple and intuitive. Filename extensions can help make filenames more meaningful.

When you are logged in, you are always associated with a working directory. Your home directory is the working directory from the time you log in until you use cd to change directories.

An absolute pathname starts with the root directory and contains all the filenames that trace a path to a given file. The pathname starts with a slash, representing the root directory, and contains additional slashes following each of the directories in the path, except for the last directory in the case of a path that points to a directory file.

A relative pathname is similar to an absolute pathname but traces the path starting from the working directory. A simple filename is the last element of a pathname and is a form of a relative pathname; it represents a file in the working directory.

A Linux filesystem contains many important directories, including /usr/bin, which stores most of the Linux utilities, and /dev, which stores device files, many of which represent physical pieces of hardware. An important standard file is /etc/passwd; it contains information about users, such as a user’s ID and full name.

Among the attributes associated with each file are access permissions. They determine who can access the file and how the file may be accessed. Three groups of users can potentially access the file: the owner, the members of a group, and all other users. An ordinary file can be accessed in three ways: read, write, and execute. The ls utility with the –l option displays these permissions. For directories, execute access is redefined to mean that the directory can be searched.

The owner of a file or a user working with root privileges can use the chmod utility to change the access permissions of a file. This utility specifies read, write, and execute permissions for the file’s owner, the group, and all other users on the system.

ACLs (Access Control Lists) provide finer-grained control over which users can access specific directories and files than do traditional Linux permissions. Using ACLs you can specify the ways in which each of several users can access a directory or file. Few utilities preserve ACLs when working with files.

An ordinary file stores user data, such as textual information, programs, or images. A directory is a standard-format disk file that stores information, including names, about ordinary files and other directory files. An inode is a data structure, stored on disk, that defines a file’s existence and is identified by an inode number. A directory relates each of the filenames it stores to an inode.

A link is a pointer to a file. You can have several links to a file so you can share the file with other users or have the file appear in more than one directory. Because only one copy of a file with multiple links exists, changing the file through any one link causes the changes to appear in all the links. Hard links cannot link directories or span filesystems, whereas symbolic links can.

Table 6-3 summarizes the utilities introduced in this chapter.

Table 6-3 Utilities introduced in Chapter 6

Exercises

1. Is each of the following an absolute pathname, a relative pathname, or a simple filename?

a. milk_co

b. correspond/business/milk_co

c. /home/max

d. /home/max/literature/promo

e. ..

f. letter.0210

2. List the commands you can use to perform these operations:

a. Make your home directory the working directory

b. Identify the working directory

3. If the working directory is /home/max with a subdirectory named literature, give three sets of commands you can use to create a subdirectory named classics under literature. Also give several sets of commands you can use to remove the classics directory and its contents.

4. The df utility displays all mounted filesystems along with information about each. Use the df utility with the –h (human-readable) option to answer the following questions.

a. How many filesystems are mounted on your Linux system?

b. Which filesystem stores your home directory?

c. Assuming your answer to exercise 4a is two or more, attempt to create a hard link to a file on another filesystem. What error message do you get? What happens when you attempt to create a symbolic link to the file instead?

5. Suppose you have a file that is linked to a file owned by another user. How can you ensure that changes to the file are no longer shared?

6. You should have read permission for the /etc/passwd file. To answer the following questions, use cat or less to display /etc/passwd. Look at the fields of information in /etc/passwd for the users on the local system.

a. Which character is used to separate fields in /etc/passwd?

b. How many fields are used to describe each user?

c. How many users are on the local system?

d. How many different login shells are in use on your system? (Hint: Look at the last field.)

e. The second field of /etc/passwd stores user passwords in encoded form. If the password field contains an x, your system uses shadow passwords and stores the encoded passwords elsewhere. Does your system use shadow passwords?

7. If /home/zach/draft and /home/max/letter are links to the same file and the following sequence of events occurs, what will be the date in the opening of the letter?

a. Max gives the command vim letter.

b. Zach gives the command vim draft.

c. Zach changes the date in the opening of the letter to January 31, writes the file, and exits from vim.

d. Max changes the date to February 1, writes the file, and exits from vim.

8. Suppose a user belongs to a group that has all permissions on a file named jobs_list, but the user, as the owner of the file, has no permissions. Describe which operations, if any, the user/owner can perform on jobs_list. Which command can the user/owner give that will grant the user/owner all permissions on the file?

9. Does the root directory have any subdirectories you cannot search as an ordinary user? Does the root directory have any subdirectories you cannot read as a regular user? Explain.

10. Assume you are given the directory structure shown in Figure 6-2 on page 177 and the following directory permissions:

d--x--x--- 3 zach pubs 512 2010-03-10 15:16 business
drwxr-xr-x 2 zach pubs 512 2010-03-10 15:16 business/milk_co

For each category of permissions—owner, group, and other—what happens when you run each of the following commands? Assume the working directory is the parent of correspond and that the file cheese_co is readable by everyone.

a. cd correspond/business/milk_co

b. ls –l correspond/business

c. cat correspond/business/cheese_co

Advanced Exercises

11. What is an inode? What happens to the inode when you move a file within a filesystem?

12. What does the .. entry in a directory point to? What does this entry point to in the root (/) directory?

13. How can you create a file named –i? Which techniques do not work, and why do they not work? How can you remove the file named –i?

14. Suppose the working directory contains a single file named andor. What error message do you get when you run the following command line?

$ mv andor and\/or

Under what circumstances is it possible to run the commaìnd without producing an error?

15. The ls –i command displays a filename preceded by the inode number of the file (page 206). Write a command to output inode/filename pairs for the files in the working directory, sorted by inode number. (Hint: Use a pipeline.)

16. Do you think the system administrator has access to a program that can decode user passwords? Why or why not? (See exercise 6.)

17. Is it possible to distinguish a file from a hard link to a file? That is, given a filename, can you tell whether it was created using an ln command? Explain.

18. Explain the error messages displayed in the following sequence of commands:

$ ls -l
total 1
drwxrwxr-x. 2 max pubs 1024 03-02 17:57 dirtmp
$ ls dirtmp
$ rmdir dirtmp
rmdir: dirtmp: Directory not empty
$ rm dirtmp/*
rm: No match.