Next: My Home Page

Answers

The experiment can easily be performed as follows:
```
	$ cp /etc/passwd ./p0
	$ ln -s p0 p1
	$ ln -s p1 p2
	$ cat p2
	root:ltq3uhhA2dnSM:0:0:root:/root:/bin/bash
```
This sequence takes a working copy of the password file into the current directory as p0. The second line creates a symbolic link to your copy of the password file, and calls the link p1. The third line now creates a second symbolic link to p1 and calls the second link p2. Finally, the cat command is used to test if the second link (p2) can be used to access the target file at the end of the chain. And indeed it can.
If you continue to add links to the chain everything seems to work as far as adding the new links is concerned, but when you have more than six links in the chain the commands you use can no longer access the target file:
```
	$ ls -l
	total 1
	-rw-r--r--  1  pc   500	 731 Jan 13   16:19    p0
	lrwxrwxrwx  1  pc   500	 6   Jan 13  18:07     p1 -> p0
	lrwxrwxrwx  1  pc   500	 2   Jan 13  18:07     p2 -> p1
	lrwxrwxrwx  1  pc   500	 2   Jan 13  18:08     p3 -> p2
	lrwxrwxrwx  1  pc   500	 2   Jan 13  18:08     p4 -> p3
	lrwxrwxrwx  1  pc   500	 2   Jan 13  18:08     p5 -> p4	
	lrwxrwxrwx  1  pc   500	 2   Jan 13  18:08     p6 -> p5
	lrwxrwxrwx  1  pc   500	 2   Jan 13  18:09     p7 -> p6
	$ cat p7
	cat: p7: Too many	 symbolic links encountered
	$ cat p6
	root : ltq3uhhA2dnSM	:0:0: root : /root :/bin/bash
```
so while you can chain symbolic links successfully, there is a maximum usable chain length of six links.
In order to access the contents of a file you need to obtain its inode number. Bearing this in mind, the only real disadvantage with symbolic links is that each link adds an extra level of indirection to the process of finding the inode number of the target file and thus slows the process down. Hard links don't suffer from this problem as each hard link has its own copy of the number of the inode to which it refers built into it. Another point about symbolic links, which isn't really a disadvantage, but which can come as a surprise, is that a link can exist to a file which does not exist. Try to set this up and see what happens when you attempt to use the link.
Probably the most obvious way to tackle this problem is to use the ls command with the -l command line switch to find files with two or more links (these are shown in field 2 of the ls listing. You could then use the -i switch to display the inode numbers of the relevant files to see if you could find a match.
Another possibility is to remember that directories are also files and that every directory has at least two links to its inode, even if it is empty. For example, the directory ibm has a link in the root directory (called bin). But don't forget it also has another link inside the directory /bin itself (called '.' dot). Using the -d switch to ls, this can be verified as follows:
```
	$ cd /
	$ ls -id bin
	43478 bin
	$ cd /bin
	$ ls -id .
	43478   .
```
Obviously, if you try this experiment, the inode number for /bin on your system will most likely be different to mine but the important thing is that the two inode numbers you get out should both be the same.
Because you have set the temp directory up with read permission for you as its owner, the ls command which runs on your behalf is able to read the list of file names contained in the directory and list them as expected no other permissions are required to do this:
```
	$ ls temp passwd
```
Now, executing the command with the -l switch will give an output similar to the following:
```
	$ ls -l temp
	ls: temp/passwd: Permission denied total 0
```
What this says is that ls discovered the existence of the passwd file in the temp directory (which you know it can, from the previous question) but after that it was denied permission to perform some operation. What actually happens is that with the -l command line switch, ls cannot get all of the information it needs to display just from the directory, so it needs to access the files themselves for the extra information. Now, however, because you do not have search permission on the directory, ls is denied permission to use the directory as a component of a file pathname. Consequently, when ls tries to find the extra information it requires it is denied access to the files, even though it knows they are there, having got the names from the directory itself. To make ls execute as expected you need to change the permission on the temp directory as follows:
```
	$ chmod 500 temp
	$ ls -l temp
	total 1
	-rw-r--r--  1 pc	500	731 Jan 13 16:19 passwd
```

Next: My Home Page