![]() |
|||||
|
|
∂ : Action to Take : read about files and symbolic link magic before we move on
![]() click image for full size We have a few more little steps to take before name resolution will work for you. We need to correctly place a symbolic link for our file /etc/inet/resolv.conf into the directory /etc. If you have no idea what a symbolic link is then let me explain briefly. Think of a symbolic link ( symlink ) like a signpost that says “this way to your file”. Like a street sign may be placed somewhere near a street and pointing towards the destination. Its not really the actual file that you need but it will act just like it. That is the simplest way I can describe it. You need to change directories into /etc with cd /etc and then fix up the permissions ( security rights ) on the file /etc/inet/resolv.conf. Then we create the symlink. Like so :
# cd /etc
#
# chown root:sys ./inet/resolv.conf
#
The command chown will change the ownership of that file such that the user root and the group sys own that file. The word own isn't really accurate. Really we are granting rights to that specific file and with the command ls we can see the details :
# ls -lap ./inet/resolv.conf
-rw-r--r-- 1 root sys 94 Apr 9 00:40 ./inet/resolv.conf
#
There you see that I used the parameters -lap with the command ls to dig out details about the file. The pile of characters at the beginning of the output are really important. What you are seeing there are the rights or permissions that various accounts or groups have. Think of it as seven letters where a dash means nothing here. So there you see a leading dash followed by rw-r--r--. Forget that leading dash for now as it would take a while to explain. Just focus on those six right most characters there. They are actually arranged in groups of three letters at a time and you can read them like this : rw- and then r-- and finally r--. Each of those three characters specifically determines the security or access rights of a given user or a specific group. The first set there determines what the owner of the file can do. In this case the owner is shown to be the root user and the rights are read plus write. That is what rw- means. It means read plus write access is granted to the user account associated with this file. The next three letters determines access for a given group and then the last three letters specifies everyone and anyone. So in both cases we see that read access is granted. Not write access. That means that only the root user can both read and write the file while everyone else can simply read. A few examples never hurt anyone and so therefore consider the following :
Some file exists that was created by a user phil. He also set the group access
of the file to some group called dvd. He then granted read access to the group
and no one else. The file looks like so :
$ ls -lap foo
----rw---- 1 phil dvd 9 Apr 9 00:55 foo
Some user, not phil, may be a member of the group dvd and then read what is
in that file :
$ cat foo
security
Any user that is not a member of the group dvd will see this :
$ cat foo
cat: cannot open foo
Furthermore, if the user phil is removed from the group dvd then he too
will lose access to the file because it specifically denies access to
him. Only members of the group dvd may access that file for read and
write and no one else.
Guess what? There is one user that can always read that file. The user known as root is the superuser. All seeing and all powerful the root user can even open files that look like this :
# ls -lap foo
---------- 1 phil dvd 9 Apr 9 00:55 foo
# cat foo
security
Pretty silly looking file security there on that example. It should be illegal to grant no access to a file but there you see the absurd on display. Almost anything is possible it seems. Even when it should be impossible. Regardless, I have strayed from the intent and purpose while spilling out education. Let's get back on track. A symbolic link is like a little pointer that sits on a disk and points to some file somewhere else. Let me give you an example :
# echo "bar" > foo
# ln -s ./foo ./bar
# cat bar
bar
# ln -s ./bar ./foobar
# ls -lap foo bar foobar
lrwxrwxrwx 1 root root 5 Apr 9 01:14 bar -> ./foo
-rw-r--r-- 1 root root 4 Apr 9 01:13 foo
lrwxrwxrwx 1 root root 5 Apr 9 01:14 foobar -> ./bar
Now here is the play by play for the above. First I use the echo command to toss the word “bar” into a file named foo. The echo command does not do much more than what it sounds like; it just echoes out whatever input it receives. The greater than sign there > says to take the output and stuff it into a file called foo. So the file foo exists and it contains the three characters “bar”. Plus a special character called a “carriage return”. ( Hence 4 bytes as you will see later. ) Next I use the ln link command to create a symlink from the real file foo to an imaginary file called bar. The leading dot and slash are simply pedantic ways of saying that I want these files in this current directory. Next I use the cat command to dump that new imaginary file called bar onto the terminal. Sure enough the result is just “bar”. To add another level of complexity I then create a symlink from foobar to bar. Neither of which are real files! More absurdity really but it allows us to create symlinks that point to symlinks that point to files. At least we hope that the file exists. The final command there shows us a detailed list ( via ls ) which reveals that foo is a real file with permissions and size. There exists two symlinks that each have radical looking permissions as well as a leading letter l ( lower case l as in link ). For the sake of being complete I will show you that we can get into trouble by destroying the file that is real and then we are left with nothing but symlinks that point, ultimately, nowhere. Thus :
# echo "foo" >> foo
# ls -lap foo bar foobar
lrwxrwxrwx 1 root root 5 Apr 9 01:14 bar -> ./foo
-rw-r--r-- 1 root root 8 Apr 9 01:29 foo
lrwxrwxrwx 1 root root 5 Apr 9 01:14 foobar -> ./bar
# rm foo
# ls -lap foo bar foobar
foo: No such file or directory
lrwxrwxrwx 1 root root 5 Apr 9 01:14 bar -> ./foo
lrwxrwxrwx 1 root root 5 Apr 9 01:14 foobar -> ./bar
There you see that I used echo again but this time I threw a double greater than sign after it. The double > indicates that the output from the echo command is to be appended to the end of the file foo. Thus you now see that foo becomes eight bytes in size. The next thing that you see is that I actually remove the file foo from existence with the rm command. The file is gone but the symlinks that once point to it are still there. This is where a symlink is not very useful. One final atrocity and abuse of symbolic links is the circular link thus :
# ln -s ./foobar ./foo
# ls -lap foo bar foobar
lrwxrwxrwx 1 root root 5 Apr 9 01:14 bar -> ./foo
lrwxrwxrwx 1 root root 8 Apr 9 01:33 foo -> ./foobar
lrwxrwxrwx 1 root root 5 Apr 9 01:14 foobar -> ./bar
#
If that looks insane then you are correct to feel that way. No file called foo even exists anymore but we have a symlink foobar that points to bar which points to foo which is in turn a symlink that points to foobar. Madness. Now you will see a file that even the root user can not access because it does not exist :
# cat foo
cat: cannot open foo
# ls -l foo bar foobar
lrwxrwxrwx 1 root root 5 Apr 9 01:14 bar -> ./foo
lrwxrwxrwx 1 root root 8 Apr 9 01:33 foo -> ./foobar
lrwxrwxrwx 1 root root 5 Apr 9 01:14 foobar -> ./bar
# unlink foobar
# unlink bar
# ls -l foo bar foobar
bar: No such file or directory
foobar: No such file or directory
lrwxrwxrwx 1 root root 8 Apr 9 01:33 foo -> ./foobar
#
The thing called foo still says that it is 8 bytes in size but it is a symlink that points to nowhere. The normal symbolic links needed just five bytes on the disk but this thing that we are left with needs 8 bytes. I don't know what it is but I think I had better delete it. The lesson here is that you need to be careful with symbolic links and with file permissions. Yes you can access just about anything as root so long as the thing in question is sane. You can do damage through a sequence of perfectly logical steps and render an illogical result. Simply be careful is all I am saying here. Have a look at the picture above and let's edit the /etc/nsswitch.conf configuration file. |
|||||||