Chapter 18 - Special Directories and Files

This chapter will cover the following exam objectives:

5.4: Special Directories and Files
Weight: 1
Special directories and files on a Linux system including special permissions.
Key Knowledge Areas:

 Using temporary files and directories

Section 18.4
 Symbolic links
Section 18.5.2

Chapter 18 - Special Directories and Files

/tmp/

Directory where all users are allowed to create temporary files.

Section 18.4

/var/tmp/

Directory where all users are allowed to create temporary files.

Section 18.4

ln -s

Command used to create a symbolic link.

Section 18.5.2

ls -d

The -d option of the ls command is used to refer to the current directory, and not the
contents within it.
Section 18.3.2

sticky bit

Permission is used to prevent other users from deleting files that they do not own in a
shared directory.
Section 18.4

18.1 Introduction
In most circumstances, the basic Linux permissions, read, write, and execute, are enough to
accommodate the security needs of individual users or organizations.
However, when multiple users need to work routinely on the same directories and files, these
permissions may not be enough. The special permissions setuid, setgid and the sticky bit are
designed to address these concerns.
  Previous

 Next 
18.2 Setuid
When the setuid permission is set on an executable binary file (a program) the binary file is run
as the owner of the file, not as the user who executed it. This permission is set on a handful of
system utilities so that they can be run by normal users, but executed with the permissions of
root, providing access to system files that the normal user doesn't normally have access to.
Consider the following scenario in which the user sysadmin attempts to view the contents of
the /etc/shadow file:

sysadmin@localhost:~$ more /etc/shadow

/etc/shadow: Permission denied
sysadmin@localhost:~$ ls -l /etc/shadow
-rw-r-----. 1 root root 5195 Oct 21 19:57 /etc/shadow

The permissions on /etc/shadow do not allow normal users to view (or modify) the file. Since
the file is owned by the root user, the administrator can temporarily modify the permissions to
view or modify this file.
Now consider the passwd command. When this command runs, it modifies
the /etc/shadow file, which seems impossible because other commands that
the sysadmin user runs that try to access this file fail. So, why can the sysadmin user modify
the /etc/shadow file while running the passwd command when normally this user has no
access to the file?
The passwd command has the special setuid permission set. When the passwd command is run,
and the command accesses the /etc/shadow file, the system acts as if the user accessing the
file is the owner of the passwd command (the root user), not the user who is running the
command.
You can see this permission set by running the ls -l command:

sysadmin@localhost:~$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 31768 Jan 28 2010 /usr/bin/passwd

Notice the output of the ls command above; the setuid permission is represented by the s in the
owner permissions where the execute permission would normally be represented. A
lowercase s means that both the setuid and execute permission are set, while an
uppercase S means that only setuid and not the user execute permission is set.
Like the read, write and execute permissions, special permissions can be set with
the chmod command, using either the symbolic and octal methods.
To add the setuid permission symbolically, run:

chmod u+s file

To add the setuid permission numerically, add 4000 to the file's existing permissions (assume
the file originally had 775 for its permission in the following example):

chmod 4775 file

To remove the setuid permission symbolically, run:

chmod u-s file

To remove the setuid permission numerically, subtract 4000 from the file's existing permissions:

chmod 0775 file

Previously, we set permission with the octal method using three-digit codes. When a three-digit
code is provided, the chmod command assumes that the first digit before the three-digit code is 0.
Only when four digits are specified is a special permission set.
If three digits are specified when changing the permission on a file that already has a special
permission set, the first digit will be set to 0, and the special permission will be removed from the
file.

  Previous

 Next 

18.3 Setgid
The setgid permission is similar to setuid, but it makes use of the group owner permissions.
There are two forms of setgid permissions: setgid on a file and setgid on a directory. The
behavior of setgid depends on whether it is set on a file or directory.

  Previous

 Next 

18.3.1 Setgid on Files

The setgid permission on a file is very similar to setuid; it allows a user to run an executable
binary file in a manner that provides them additional (temporary) group access. The system
allows the user running the command to effectively belong to the group that owns the file, but
only in the setgid program.
A good example of the setgid permission on an executable file is
the /usr/bin/wall command. Notice the permissions for this file as well as the group owner:

sysadmin@localhost:~$ ls -l /usr/bin/wall
-rwxr-sr-x 1 root tty 30800 May 16 2018 /usr/bin/wall

You can see that this file is setgid by the presence of the s in the group's execute position. Due
to this executable being owned by the tty group, when a user executes this command, the
command is able to access files that are group owned by the tty group.
This access is important because the /usr/bin/wall command sends messages to terminals,
which is accomplished by writing data to files like the following:

sysadmin@localhost:~$ ls -l /dev/tty?
crw--w----. 1 root tty 4, 0 Mar 29 2013 /dev/tty0
crw--w----. 1 root tty 4, 1 Oct 21 19:57 /dev/tty1

Note that the tty group has write permission on the files above while users who are not in
the tty group ("others") have no permissions on these files. Without the setgid permission,
the /usr/bin/wall command would fail.

  Previous

 Next 

18.3.2 Setgid on Directories

When set on a directory, the setgid permission causes files created in the directory to be owned
by the group that owns the directory automatically. This behavior is contrary to how new file
group ownership would normally function, as by default new files are group owned by the primary
group of the user who created the file.
In addition, any directories created within a directory with the setgid permission set are not only
owned by the group that owns the setgid directory, but the new directory automatically has setgid
set on it as well. In other words, if a directory is setgid, then any directories created within that
directory inherit the setgid permission.
By default when the ls command is executed on a directory, it outputs information on the files
contained within the directory. To view information about the directory itself add the -d option.
Used with the -l option, it can be used to determine if the setgid permission is set. The following
example shows that the /tmp/data directory has the setgid permission set and that it is owned
by the demo group.

sysadmin@localhost:~$ ls -ld /tmp/data

drwxrwsrwx. 2 root demo 4096 Oct 30 23:20 /tmp/data

In a long listing, the setgid permission is represented by an s in the group execute position. A
lowercase s means that both setgid and group execute permissions are set:

drwxrwsrwx. 2 root demo 4096 Oct 30 23:20 /tmp/data

An uppercase S means that only setgid and not group execute permission is set. If you see an
uppercase S in the group execute position of the permissions, then it indicates that although the
setgid permission is set, it is not really in effect because the group lacks the execute permission
to use it:

drwxrwSr-x. 2 root root 5036 Oct 30 23:22 /tmp/data2

Typically files created by the user sysadmin are owned by their primary group, also
called sysadmin.

sysadmin@localhost:~$ id
uid=500(sysadmin) gid=500(sysadmin)
groups=500(sysadmin),10001(research),10002(development)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
The UID and GID information in the example above may differ from the output in our virtual
environment.
However, if the user sysadmin creates a file in the /tmp/data directory, the setgid directory
from the preceding example, the group ownership of the file isn't the sysadmin group, but rather
the group that owns the directory demo:

sysadmin@localhost:~$ touch /tmp/data/file.txt

sysadmin@localhost:~$ ls -ld /tmp/data/file.txt
-rw-rw-r--. 1 bob demo 0 Oct 30 23:21 /tmp/data/file.txt

Why would an administrator want to set up a setgid directory? First, consider the following user
accounts:

 The user bob is a member of the payroll group.

 The user sue is a member of the staff group.
 The user tim is a member of the acct group.

In this scenario, these three users need to work on a joint project. They approach the
administrator to ask for a shared directory in which they can work together, but that no one else
can access their files. The administrator does the following:

1. Creates a new group called team.

2. Adds bob, sue, and tim to the team group.
3. Makes a new directory called /home/team.
4. Makes the group owner of the /home/team directory be the team group.
5. Gives the /home/team directory the following permissions: rwxrwx---

As a result, bob, sue, and tim can access the /home/team directory and add files. However,

there is a potential problem: when bob creates a file in the /home/team directory, the new file is
owned by his primary group:

-rw-r-----. 1 bob payroll 100 Oct 30 23:21 /home/team/file.txt

Unfortunately, while sue and tim can access the /home/team directory, they can't do anything

with bob's file. Their permissions for that file are the others permissions (---).
If the administrator sets the setgid permission to the /home/team directory, then
when bob creates a file, it is owned the team group:

-rw-r-----. 1 bob team 100 Oct 30 23:21 /home/team/file.txt

As a result, sue and tim would have access to the file through the group owner permissions
(r--).
Certainly, bob could change the group ownership or the others permissions after creating the
file, but that would become tedious if there were many new files being created. The setgid
permission makes it easier for this situation.

  Previous

 Next 
18.3.3 Setting Setgid
Use the following syntax to add the setgid permission symbolically:

chmod g+s <file|directory>

To add the setgid permission numerically, add 2000 to the file's existing permissions (assume in
the following example that the directory originally had 775 for its permissions):

chmod 2775 <file|directory>

To remove the setgid permission symbolically, run:

chmod g-s <file|directory>

To remove the setgid permission numerically, subtract 2000 from the file's existing permissions:

chmod 0775 <file|directory>

  Previous

 Next 

18.4 Sticky Bit

The sticky bit permission is used to prevent other users from deleting files that they do not own in
a shared directory. Recall that any user with write permission on a directory can create files in
that directory, as well as delete any file in the directory, even if they do not own the file!
The sticky bit permission allows for files to be shared with other users, by changing write
permission on the directory so that users can still add and delete files in the directory, but files
can only be deleted by the owner of the file or the root user.
A good example of the use of sticky bit directories would be the /tmp and /var/tmp directories.
These directories are designed as locations where any user can create a temporary file.
Because these directories are intended to be writable by all users, they are configured to use the
sticky bit. Without this special permission, users would be able to delete any files in this directory,
including those that belong to other users.
The output of the ls -l command displays the sticky bit by a t character in the execute bit of
the others permission group:

sysadmin@localhost:~$ ls -ld /tmp

drwxrwxrwt 1 root root 4096 Mar 14 2016 /tmp

A lowercase t means that both the sticky bit and execute permissions are set for others. An
uppercase T means that only the sticky bit permission is set.
While the capital S indicated a problem with the setuid or setgid permissions, a capital T does not
necessarily indicate a problem, as long as the group owner still has the execute permission.
To set the sticky bit permission symbolically, execute a command like the following:
chmod o+t <directory>

To set the sticky bit permission numerically, add 1000 to the directory's existing permissions
(assume the directory in the following example originally had 775 for its permissions):

chmod 1775 <file|directory>

To remove the sticky permission symbolically, run:

chmod o-t <directory>

‌ o remove the sticky bit permission numerically, subtract 1000 from the directory's existing
T
permissions:

chmod 0775 <directory>

  Previous

 Next 

18.5 Links
Consider a scenario where there is a file deeply buried in the file system called:

/usr/share/doc/superbigsoftwarepackage/data/2013/october/tenth/valuable-
information.txt

Another user routinely updates this file, and you need to access it regularly. The long file name is
a not an ideal choice for you to type, but the file must reside in this location. It is also updated
frequently, so you can't simply make a copy of the file.
In a situation like this, links come in handy. You can create a file that is linked to the one that is
deeply buried. This new file could be placed in the home directory or any other convenient
location. When you access the linked file, it accesses the contents of the valuable-
information.txt file.
Each linking method, hard and symbolic, results in the same overall access, but uses different
techniques. There are pros and cons to each method, so knowing both techniques and when to
use them is important.

  Previous

 Next 

18.5.1 Creating Hard Links

To understand hard links, it is helpful to understand a little bit about how the file system keeps
track of files. For every file created, there is a block of data on the file system that stores
the metadata of the file. Metadata includes information about the file like the permissions,
ownership, and timestamps. Metadata does not include the file name or the contents of the file,
but it does include just about all other information about the file.
This metadata is called the file's inode table. The inode table also includes pointers to the other
blocks on the file system called data blocks where the data is stored.
Every file on a partition has a unique identification number called an inode number. The ls
-i command displays the inode number of a file.

sysadmin@localhost:~$ ls -i /tmp/file.txt
215220874 /tmp/file.txt

Like users and groups, what defines a file is not its name, but rather the number it has been
assigned. The inode table does not include the file name. For each file, there is also an entry that
is stored in a directory's data area (data block) that includes an association between an inode
number and a file name.
In the data block for the /etc directory, there would be a list of all of the files in this directory and
their corresponding inode number. For example:

File Name Inode Number

passwd 123

shadow 175

group 144

gshadow 897

When you attempt to access the /etc/passwd file, the system uses this table to translate the
file name into an inode number. It then retrieves the file data by looking at the information in the
inode table for the file.
Hard links are two file names that point to the same inode. For example, consider the following
directory entries:

File Name Inode Number

passwd 123

mypasswd 123

shadow 175

group 144
 File Name Inode Number

gshadow 897

Because both the passwd and mypasswd file have the same inode number, they essentially are
the same file. You can access the file data using either file name.
When you execute the ls -li command, the number that appears for each file between the
permissions and the user owner is the link count number:

sysadmin@localhost:~$ echo data > file.original

sysadmin@localhost:~$ ls -li file.*
278772 -rw-rw-r--. 1 sysadmin sysadmin 5 Oct 25 15:42 file.original

The link count number indicates how many hard links have been created. When the number is a
value of one, then the file has only one name linked to the inode.
To create hard links, the ln command is used with two arguments. The first argument is an
existing file name to link to, called a target, and the second argument is the new file name to link
to the target.

ln target link_name

When the ln command is used to create a hard link, the link count number increases by one for
each additional filename:

sysadmin@localhost:~$ ln file.original file.hard.1

sysadmin@localhost:~$ ls -li file.*
278772 -rw-rw-r--. 2 sysadmin sysadmin 5 Oct 25 15:53 file.hard.1
278772 -rw-rw-r--. 2 sysadmin sysadmin 5 Oct 25 15:53 file.original

  Previous

 Next 

18.5.2 Creating Symbolic Links

A symbolic link, also called a soft link, is simply a file that points to another file. There are several
symbolic links already on the system, including several in the /etc directory:

sysadmin@localhost:~$ ls -l /etc/grub.conf
lrwxrwxrwx. 1 root root 22 Feb 15 2011 /etc/grub.conf ->
../boot/grub/grub.conf

In the previous example, the file /etc/grub.conf "points to"

the ../boot/grub/grub.conf file. So, if you were to attempt to view the contents of
the /etc/grub.conf file, it would follow the pointer and show you the contents of
the ../boot/grub/grub.conf file.
To create a symbolic link, use the -s option with the ln command:

ln -s target link_name
sysadmin@localhost:~$ ln -s /etc/passwd mypasswd
sysadmin@localhost:~$ ls -l mypasswd
lrwxrwxrwx. 1 sysadmin sysadmin 11 Oct 31 13:17 mypasswd -> /etc/passwd

Consider This
Notice that the first bit of the ls -l output is the l character, indicating that the file type is a link.

  Previous

 Next 

18.5.3 Comparing Hard and Symbolic Links

While hard and symbolic links have the same result, the different techniques produce different
advantages and disadvantages. In fact, the advantage of one technique compensates for a
disadvantage of the other technique.
Advantage: Hard links don’t have a single point of failure.
One of the benefits of using hard links is that every file name for the file content is equivalent. If
you have five files hard linked together, then deleting any four of these files would not result in
deleting the actual file contents.
Recall that a file is associated with a unique inode number. As long as one of the hard linked files
remains, then that inode number still exists, and the file data still exists.
Symbolic links, however, have a single point of failure: the original file. Consider the following
example in which access to the data fails if the original file is deleted. The mytest.txt file is a
symbolic link to the text.txt file:

sysadmin@localhost:~$ ls -l mytest.txt
lrwxrwxrwx. 1 sysadmin sysadmin 8 Oct 31 13:29 mytest.txt -> test.txt
sysadmin@localhost:~$ more test.txt
hi there
sysadmin@localhost:~$ more mytest.txt
hi there

If the original file, the test.txt file is removed, then any files linked to it, including
the mytest.txt file, fail:

sysadmin@localhost:~$ rm test.txt
sysadmin@localhost:~$ more mytest.txt
mytest.txt: No such file or directory
sysadmin@localhost:~$ ls -l mytest.txt
lrwxrwxrwx. 1 sysadmin sysadmin 8 Oct 31 13:29 mytest.txt -> test.txt
Advantage: Soft links are easier to see.
Sometimes it can be difficult to know where the hard links to a file exist. If you see a regular file
with a link count that is greater than one, you can use the find command with the -inum search
criteria to locate the other files that have the same inode number. To find the inode number you
would first use the ls -i command:

sysadmin@localhost:~$ ls -i file.original
278772 file.original
sysadmin@localhost:~$ find / -inum 278772 2> /dev/null
/home/sysadmin/file.hard.1
/home/sysadmin/file.original

Soft links are much more visual, not requiring any extra commands beyond the ls command to
determine the link:

sysadmin@localhost:~$ ls -l mypasswd
lrwxrwxrwx. 1 sysadmin sysadmin 11 Oct 31 13:17 mypasswd -> /etc/passwd

Advantage: Soft links can link to any file.

Since each file system (partition) has a separate set of inodes, hard links cannot be created that
attempt to cross file systems:

sysadmin@localhost:~$ ln /boot/vmlinuz-2.6.32-358.6.1.el6.i686 Linux.Kernel

ln: creating hard link `Linux.Kernel' => `/boot/vmlinuz-2.6.32-
358.6.1.el6.i686': Invalid cross-device link

In the previous example, a hard link was attempted to be created between a file in the /boot file
system and the / file system; it failed because each of these file systems has a unique set of
inode numbers that can't be used outside of the filesystem.
However, because a symbolic link points to another file using a pathname, you can create a soft
link to a file in another filesystem:

sysadmin@localhost:~$ ln -s /boot/vmlinuz-2.6.32-358.6.1.el6.i686
Linux.Kernel
sysadmin@localhost:~$ ls -l Linux.Kernel
lrwxrwxrwx. 1 sysadmin sysadmin 11 Oct 31 13:17 Linux.Kernel ->
/boot/vmlinuz-2.6.32-358.6.1.el6.i686

Advantage: Soft links can link to a directory.

Another limitation of hard links is that they cannot be created on directories. The reason for this
limitation is that the operating system itself uses hard links to define the hierarchy of the directory
structure. The following example shows the error message that is displayed if you attempt to
hard link to a directory:

sysadmin@localhost:~$ ln /bin binary

ln: `/bin': hard link not allowed for directory
Linking to directories using a symbolic link is permitted:

sysadmin@localhost:~$ ln -s /bin binary

sysadmin@localhost:~$ ls -l binary
lrwxrwxrwx. 1 sysadmin sysadmin 11 Oct 31 13:17 binary -> /bin

  Previous

 Next