Linux with Operating System Concepts

sticky bit
.
Historically, the sticky bit was used to indicate whether a process, which was no longer 
executing, should remain in swap space (in case it was executed again in the near future). 
The use of the sticky bit was only provided in Unix and was largely abandoned. Linux 
implementations however have used the sticky bit for a different purpose. For Linux (and 
modern versions of Unix), the sticky bit applies only to directories and indicates that a 
writable directory has restrictions on the files therein.
Let us consider a scenario to motivate the use of the sticky bit. You have created a direc-
tory to serve as a repository for group work for users of the Linux system. You make the 
directory writable so that users can store files there. Thus, the directory’s permissions would 
need to be 777 (so that the world can write to it). This can be a dangerous setting as it would 
allow the world to not only access the contents of the directory, but also rename or delete 
the directory and any of its contents. By setting the sticky bit, the files within the directory 
can be controlled by the file’s owner or the directory’s owner, but not the rest of the world.
To establish that a directory should have its sticky bit set, you can use chmod and set 
the permissions to 1777. The initial ‘1’ bit sets the world’s executable status to ‘t.’ You can 
also set the sticky bit through the instruction 
chmod o
+
t 
directoryname
or 
chmod 
a
+
t 
directoryname
. To remove the sticky bit, reset the permissions to 777 (or a more 
reasonable 755) or use o-t (or a-t).
Assume the directory mentioned in our scenario is called pub (for public) and was cre-
ated by the user foxr. He has set his home directory’s permissions to 755 and pub’s permis-
sions to 777. Now, user zappaf has written (or copied) the file foo.txt to pub. Performing an 
ls -al on pub would show the following three lines (assuming that there are no other items 
in pub).
drwxrwxrwx. 2 foxr foxr 4096 Jul 29 08:24 .
drwxr-xr-x. 32 foxr foxr 4096 Jul 29 08:24 ..
–rw–rw–r--. 1 zappaf zappaf 1851 Jul 29 08:25 foo.txt

---

Navigating the Linux File System
◾
105
Notice that the file is not writable by anyone other than zappaf, however the directory, 
indicated by . in the 
ls -al
listing, is writable. The directory indicated by .
.
is the parent 
directory. If the parent directory were not accessible then users other than foxr would not 
be able to cd or ls into this subdirectory.
Assume dukeg accesses the directory 
~foxr/pub
and performs 
rm foo.txt
or 
mv 
foo.txt foo2.txt
. Either command would work for him because the directory 
is world-writable. Normally, we would not want to make the directory world-writable 
because this is a security violation that permits anyone to change or delete a file.
But suppose foxr alters this directory’s permissions by adding the sticky bit. He does 
this by issuing either 
chmod 1777 ~/pub
or 
chmod o
+
t ~/pub
. A long listing of 
this directory will now appear with one slight change, the directory itself has a different 
permission on world execute status:
dwrxrwxrwt. 2 foxr foxr 4096 Jul 29 08:26 .
As a result, while other users can still write files to the directory, they cannot affect the 
files already stored there. Now dukeg attempts to do the rm command and receives this 
message:
rm: remove write–protected regular file ‘foo.txt’?
If dukeg responds with y (yes), the following error arises:
rm: cannot remove ‘foo.txt’: Operation not permitted
Similarly, an attempt to mv the file results in
mv: cannot move ‘foo.txt’ to ‘foo2.txt’: Operation not permitted
dukeg is allowed to copy the file, but then this would be the case if the directory and file 
were both readable no matter if the directory was writable or had the sticky bit set.
3.6 LINUX FILE SYSTEM STRUCTURE
Upon installing Linux, you will find the file system is already populated with thousands 
of files and dozens of directories. The structure of these directories and files has been pre-
established so that system administrators and users alike can learn where to find impor-
tant files. The structure is also established to support the PATH variable and initialization 
scripts. In this section, we take a look at this structure, concentrating on what is often 
called the “top-level directories.” It is less critical for a user to understand this structure; it 
is essential for a system administrator to know it. So, while we introduce the structure here, 
we will revisit it in Chapter 10.
The top-level directories in Linux are given in Table 3.9. Some of these top-level directo-
ries are empty. Others contain subdirectories with their own structure.

---

106
◾
Linux with Operating System Concepts
Some of these top-level directories are worth exploring in more detail. Let us start with 
/dev. In Linux, I/O and storage devices are treated as files. By treating devices as files, Linux 
programs can communicate with the various devices through Linux instructions and redi-
rection. Table 3.10 provides a partial listing of the devices. The device name is sometimes 
very cryptic, for instance, sda and hda are device descriptions for hard disk drives (sda for 
SCSI and SATA, hda for IDE). Because there might be multiple instances of a device, most 
of the devices are numbered. You might find for instance hda0, hda1, hda2, sda1, sda2, 
sda3, and so forth.
As a Linux user, the most important directories are /home, /usr, and /bin. You should 
find that /usr/bin, /usr/local, /usr/sbin, and /bin are all part of your PATH variable (and 
if not, they should be added). This allows you to access the programs in these directories 
without having to denote a path to the programs. For instance, you need only type ls rather 
than /bin/ls, and env instead of /usr/bin/env. Later in the text, we will explore the /etc, /
proc, and /var directories in detail.
TABLE 3.9 
Linux Top-Level Directory Structure