5 The Filesystem
5.5 F ILE ATTRIBUTES
It is a common mistake to think that the first argument to ln -s has something to do with your current working directory. It is not resolved as a filename by ln; it’s simply used verbatim as the target of the symbolic link.
5.5 F
ILE ATTRIBUTESUnder the traditional UNIX and Linux filesystem model, every file has a set of nine permission bits that control who can read, write, and execute the contents of the file.
Together with three other bits that primarily affect the operation of executable pro-grams, these bits constitute the file’s “mode.”
The twelve mode bits are stored together with four bits of file-type information. The four file-type bits are set when the file is first created and cannot be changed, but the file’s owner and the superuser can modify the twelve mode bits with the chmod (change mode) command. Use ls -l (or ls -ld for a directory) to inspect the values of these bits. An example is given on page 82.
The permission bits
Nine permission bits determine what operations may be performed on a file and by whom. Traditional UNIX does not allow permissions to be set per-user (although Linux now supports access control lists in all major filesystems; see page 88). In-stead, three sets of permissions define access for the owner of the file, the group owners of the file, and everyone else. Each set has three bits: a read bit, a write bit, and an execute bit.
It’s convenient to discuss file permissions in terms of octal (base 8) numbers because each digit of an octal number represents three bits and each group of permission bits consists of three bits. The topmost three bits (with octal values of 400, 200, and 100) control access for the owner. The second three (40, 20, and 10) control access for the group. The last three (4, 2, and 1) control access for everyone else (“the world”). In each triplet, the high bit is the read bit, the middle bit is the write bit, and the low bit is the execute bit.
Each user fits into only one of the three permission sets. The permissions used are those that are most specific. For example, the owner of a file always has access deter-mined by the owner permission bits and never the group permission bits. It is possi-ble for the “other” and “group” categories to have more access than the owner, al-though this configuration is rarely used.
On a regular file, the read bit allows the file to be opened and read. The write bit allows the contents of the file to be modified or truncated; however, the ability to delete or rename (or delete and then recreate!) the file is controlled by the permis-sions on its parent directory, because that is where the name-to-dataspace mapping is actually stored.
The execute bit allows the file to be executed. There are two types of executable files:
binaries, which the CPU runs directly, and scripts, which must be interpreted by a shell or some other program. By convention, scripts begin with a line similar to
#!/usr/bin/perl
that specifies an appropriate interpreter. Nonbinary executable files that do not spec-ify an interpreter are assumed (by your shell) to be bash or sh scripts.9
For a directory, the execute bit (often called the “search” or “scan” bit in this context) allows the directory to be entered or passed through while a pathname is evaluated, but not to have its contents listed. The combination of read and execute bits allows the contents of the directory to be listed. The combination of write and execute bits allows files to be created, deleted, and renamed within the directory.
The setuid and setgid bits
The bits with octal values 4000 and 2000 are the setuid and setgid bits. When set on executable files, these bits allow programs to access files and processes that would otherwise be off-limits to the user that runs them. The setuid/setgid mechanism for executables is described on page 45.
When set on a directory, the setgid bit causes newly created files within the directory to take on the group ownership of the directory rather than the default group of the user that created the file. This convention makes it easier to share a directory of files among several users, as long as they all belong to a common group. This interpreta-tion of the setgid bit is unrelated to its meaning when set on an executable file, but there is never any ambiguity as to which meaning is appropriate.
You can also set the setgid bit on nonexecutable plain files to request special locking behavior when the file is opened. However, we’ve never seen this feature used.
The sticky bit
The bit with octal value 1000 is called the sticky bit. It was of historical importance as a modifier for executable files on early UNIX systems. However, that meaning of the sticky bit is now obsolete and modern systems silently ignore it.
If the sticky bit is set on a directory, the filesystem won’t allow you to delete or rename a file unless you are the owner of the directory, the owner of the file, or the superuser.
Having write permission on the directory is not enough. This convention helps make directories like /tmp a little more private and secure.
Viewing file attributes
The filesystem maintains about forty separate pieces of information for each file, but most of them are useful only to the filesystem itself. As a system administrator, you
9. The kernel understands the #! (“shebang”) syntax and acts on it directly. However, if the interpreter is not specified completely and correctly, the kernel will refuse to execute the file. The shell then makes a second attempt to execute the script by calling sh.
The Filesystem
5.5 File attributes 83
will be concerned mostly with the link count, owner, group, mode, size, last access time, last modification time, and type. You can inspect all of these with ls -l (or ls -ld for a directory).
An attribute change time is also maintained for each file. The conventional name for this time (the “ctime,” short for “change time”) leads some people to believe that it is the file’s creation time. Unfortunately, it is not; it just records the time that the at-tributes of the file (owner, mode, etc.) were last changed (as opposed to the time at which the file’s contents were modified).
Consider the following example:
$ls -l /bin/gzip
-rwxr-xr-x 3 root root 57136 Jun 15 2004 /bin/gzip
The first field specifies the file’s type and mode. The first character is a dash, so the file is a regular file. (See Table 5.3 on page 77 for other codes.)
The next nine characters in this field are the three sets of permission bits. The order is owner-group-other, and the order of bits within each set is read-write-execute.
Although these bits have only binary values, ls shows them symbolically with the let-ters r, w, and x for read, write, and execute. In this case, the owner has all permissions on the file and everyone else has only read and execute permission.
If the setuid bit had been set, the x representing the owner’s execute permission would have been replaced with an s, and if the setgid bit had been set, the x for the group would also have been replaced with an s. The last character of the permissions (execute permission for “other”) is shown as t if the sticky bit of the file is turned on.
If either the setuid/setgid bit or the sticky bit is set but the corresponding execute bit is not, these bits appear as S or T.
The next field in the listing is the link count for the file. In this case it is 3, indicating that /bin/gzip is just one of three names for this file (the others are /bin/gunzip and /bin/zcat). Every time a hard link is made to a file, the count is incremented by 1.
All directories will have at least two hard links: the link from the parent directory and the link from the special file “.” inside the directory itself. Symbolic links do not affect the link count.
The next two fields in the lsoutput are the owner and group owner of the file. In this example, the file’s owner is root, and the file also belongs to the group named root.
The filesystem actually stores these as the user and group ID numbers rather than as names. If the text versions (names) can’t be determined, then these fields contain numbers. This might happen if the user or group that owns the file has been deleted from the /etc/passwd or /etc/group file. It could also indicate a problem with your NIS or LDAP database (if you use one); see Chapter 17.
The next field is the size of the file in bytes. This file is 57,136 bytes long, or about 56K.10Next comes the date of last modification: June 15, 2004. The last field in the listing is the name of the file, /bin/gzip.
ls output is slightly different for a device file. For example:
$ls -l /dev/tty0
crw-rw---- 1 root root 4, 0 Jun 11 20:41 /dev/tty0
Most fields are the same, but instead of a size in bytes, ls shows the major and minor device numbers. /dev/tty0is the first virtual console, controlled by device driver 4 (the terminal driver).
One ls option that’s useful for scoping out hard links is -i, which makes ls show each file’s “inode number.” Without going into too much detail about filesystem imple-mentations, we’ll just say that the inode number is an index into a table that enu-merates all the files in the filesystem. Inodes are the “things” that are pointed to by directory entries; entries that are hard links to the same file have the same inode number. To figure out a complex web of links, you needls -li to show link counts and inode numbers along with find to search for matches.11
The system automatically keeps track of modification time stamps, link counts, and file size information. Conversely, permission bits, ownership, and group ownership change only when they are specifically altered.
Some other ls options that are important to know are -a to show all entries in a directory (even files whose names start with a dot), -t to sort files by modification time (or -tr to sort in reverse chronological order), -F to show the names of files in a way that distinguishes directories and executable files, -R to list recursively, and -h to show file sizes in a human-readable form (e.g., 8K or 53M).
chmod: change permissions
The chmod command changes the permissions on a file. Only the owner of the file and the superuser can change its permissions. To use the command on early UNIX systems, you had to learn a bit of octal notation, but current versions accept either octal notation or a mnemonic syntax. The octal syntax is generally more convenient for administrators, but it can only be used to specify an absolute value for the permis-sion bits. The mnemonic syntax can modify some bits while leaving others alone.
The first argument tochmodis a specification of the permissions to be assigned, and the second and subsequent arguments are names of files on which permissions
10. K stands for kilo, a metric prefix meaning 1,000; however, computer types have bastardized it into meaning 210 or 1,024. Similarly, a computer megabyte is not really a million bytes but rather 220 or 1,048,576 bytes. The International Electrotechnical Commission is promoting a new set of numeric prefixes (such as kibi- and mebi-) that are based explicitly on powers of 2. At this point, it seems unlikely that common usage will change. To add to the confusion, even the power-of-2 units are not used consistently. RAM is denominated in powers of 2, but network bandwidth is always a power of 10.
Storage space is quoted in power-of-10 units by manufacturers and power-of-2 units by everyone else.
11. Try findmountpoint-xdev -inuminode-print.
The Filesystem
5.5 File attributes 85
should be changed. In the octal case, the first octal digit of the specification is for the owner, the second is for the group, and the third is for everyone else. If you want to turn on the setuid, setgid, or sticky bits, you use four octal digits rather than three, with the three special bits forming the first digit.
Table 5.4 illustrates the eight possible combinations for each set of three bits, where r,w, and x stand for read, write, and execute.
For example, chmod 711 myprog gives all permissions to the owner and execute-only permission to everyone else.12
The full details of chmod’s mnemonic syntax can be found in the chmod man page.
Some examples of mnemonic specifications are shown in Table 5.5.
The hard part about using the mnemonic syntax is remembering whethero stands for “owner” or “other”; “other” is correct. Just rememberuandgby analogy to UID and GID; only one possibility will be left.
You can also specify the modes to be assigned by analogy with an existing file. For example,chmod --reference=filea fileb makes fileb’s mode the same as filea’s.
chmodcan update the file permissions within a directory recursively with the-R option. However, this is trickier than it looks, since the enclosed files and directories may not all share the same attributes (for example, some might be executable files Table 5.4 Permission encoding for chmod
Octal Binary Perms Octal Binary Perms
0 000 – – – 4 100 r– –
1 001 – – x 5 101 r–x
2 010 –w– 6 110 rw–
3 011 –wx 7 111 rwx
12. If myprog were a shell script, it would need both read and execute permission turned on. For the script to be run by an interpreter, it must be opened and read like a text file. Binary files are executed directly by the kernel and therefore do not need read permission turned on.
Table 5.5 Examples of chmod’s mnemonic syntax
Spec Meaning
u+w Adds write permission for the owner of the file
ug=rw,o=r Gives r/w permission to owner and group, and read permission to others a-x Removes execute permission for all categories (owner/group/other) ug=srx,o= Makes the file setuid and setgid and gives r/x permission to the owner
and group only
g=u Makes the group permissions be the same as the owner permissions
while others are text files). The mnemonic syntax is particularly useful with -R be-cause any bits whose values you don’t set explicitly are left alone. For example,
$chmod -R g+w mydir
adds group write permission to mydir and all its contents without messing up the execute bits of directories and programs.
chown: change ownership and group
The chowncommand changes a file’s ownership and group ownership. Its syntax mirrors that of chmod, except that the first argument specifies the new owner and group in the form user:group. You can omit either user or group. If there is no group, you don’t need the colon either, although you can include it to make chown set the group to user’s default group. The form user.group is also accepted, for historical reasons, although it’s a bit degenerate since usernames can include dots.
To change a file’s group, you must either be the owner of the file and belong to the group you’re changing to or be the superuser. You must be the superuser to change a file’s owner.
Like chmod,chownoffers the recursive -Rflag to change the settings of a directory and all the files underneath it. For example, the sequence
#chmod 755 ~matt
#chown -R matt:staff ~matt
might be used to set up the home directory of a new user after you had copied in the default startup files. Make sure that you don’t try to chown the new user’s dot files with a command such as
#chown -R matt:staff ~matt/.*
The pattern will match ~matt/.. and will therefore end up changing the ownerships of the parent directory and probably the home directories of other users.
Traditional UNIX uses a separate command, chgrp, to change the group owner of a file. Linux has chgrp too. It works just like chown; feel free to use it if you find it easier to remember.
umask: assign default permissions
You can use the built-in shell command umask to influence the default permissions given to the files you create. The umask is specified as a three-digit octal value that represents the permissions to take away. When a file is created, its permissions are set to whatever the creating program requests minus whatever the umask forbids.
Thus, the individual digits of the umask allow the permissions shown in Table 5.6.
For example, umask 027 allows all permissions for the owner but forbids write per-mission to the group and allows no perper-missions for anyone else. The default umask value is often 022, which denies write permission to the group and world but allows read permission.
The Filesystem
5.5 File attributes 87
See Chapter 6 for more information about startup files.
You cannot force users to have a particular umask value because they can always reset it to whatever they want. However, you can put a suitable default in the sample .profile and .cshrc files that you give to new users.
Bonus flags
Linux’s ext2fs and ext3fs filesystems define some supplemental attributes you can turn on to request special filesystem semantics (“request” being the operative word, since many of the flags haven’t actually been implemented). For example, one flag makes a file append-only and another makes it immutable and undeletable.
Since these flags don’t apply to filesystems other than the ext* series, Linux uses spe-cial commands, lsattrandchattr,to view and change them. Table 5.7 lists the flags that actually work (currently only about 50% of those mentioned in the man page).
With the possible exception of the “no backup” flag, it’s not clear that any of these features offer much day-to-day value. The immutable and append-only flags were largely conceived as ways to make the system more resistant to tampering by hackers or hostile code. Unfortunately, they can confuse software and protect only against hackers that don’t know enough to use chattr -ia.13 Real-world experience has shown that these flags are more often used by hackers than against them.
The S and D options for synchronous writes also merit a special caution. Since they force all filesystem pages associated with a file or directory to be written out imme-Table 5.6 Permission encoding for umask
Octal Binary Perms Octal Binary Perms
0 000 rwx 4 100 –wx
1 001 rw– 5 101 –w–
2 010 r–x 6 110 ––x
3 011 r–– 7 111 –––
Table 5.7 Ext2fs and ext3fs bonus flags Flag Meaning
A Never update access time (st_atime; for performance) a Allow writing only in append mode (only root can set) D Force directory updates to be written synchronously d No backup—make dump ignore this file
i Make file immutable and undeletable (only root can set) j Keep a journal for data changes as well as metadata S Force changes to be written synchronously (no buffering)
13. The capability mechanism described on page 683 can make it harder to turn off these bits, but the fea-ture is not widely used.
diately on changes, they might seem to offer additional protection against data loss in the event of a crash. However, the order of operations for synchronous updates is unusual and has been known to confuse fsck; recovery of a damaged filesystem
diately on changes, they might seem to offer additional protection against data loss in the event of a crash. However, the order of operations for synchronous updates is unusual and has been known to confuse fsck; recovery of a damaged filesystem