Lab 12.2 - Further explanation required. Thank you

josepmaria

I do not understand the second part of the solution of lab 12.2

Question states:

but answer types ls /usr

Why is /usr included in the answer part?

Thanks in advance.

KevinCSmallwood

The point of the $PATH environment variable is which "ls" command is found and executed first. The system will use your $PATH environment variable contents to look for a command called "ls" in the order (from left to right) that it finds in your $PATH variable. So, we have two "ls" commands represented as files. One, the standard Linux system version, is found in the /bin directory (/bin/ls). The other, in this example, is found in /tmp (as in /tmp/ls--NOTE, this is not standard Linux!). So, the point of this exercise is to show you that the $PATH variable represents an ordered list of directories to search for the commands that you type in. In this case, the "ls" command. In the first case, you put "/tmp" at the end of the list of directories to search for commands. By default, "/bin" is earlier in the standard list of directories that are searched. So, /bin/ls (the stock and standard Linux "ls" command) is found first and is the program executed. We are using "/usr" simply as the argument to the "ls" command. We could just as easily used "ls ~" (your $HOME or login directory) or "ls /" (the root directory of the filesystem). We could have just used "ls" without an argument since it would default to listing the contents of our current working director (the directory where we currently are located within the filesystem tree). Again, the main point is that we are using the "/bin/ls" command rather than the "/tmp/ls" command.

In the second case, you put "/tmp" at the beginning of our search path in the $PATH variable. This means that "/tmp" will be searched first. If an "ls" executable file is found in "/tmp" (it is found there), it will be the one executed (instead of the standard Linux "/bin/ls" command!).

The point of all this is kind of subtle. Have you ever heard of the concept of a Trojan Horse? Yes, it comes from Greek Mythology, but in computer terms, it is hiding something that usually is malicious so that you use it instead of the real thing that you wanted to use. If you add a publicly writable ("/tmp" is writable by all users, so all users could put anything in that directory!) to your executable $PATH near the front of the path, you may end up executing a malicious program (that does bad things to you!) instead of the program that you intended to execute. For this reason, it is advisable that you only have Linux system directories at the beginning of your executable path and add less secure directories at the end of your executable path, and then only directories that you can trust.

josepmaria

@KevinCSmallwood thanks for your time and detailed answer. I really appreciate it.

Now I see I was focusing on a minor detail of the lab ( “/usr” part of the answer), and this prevented me from understanding the main point of the lab.

From your answer I understand that this lab presents 2 tricky parts, the first one is the name of the program “ls” and the second one is the location “/tmp”.

I can see that the first answer (putting the “/tmp” at the end of the PATH) does not solve the problem, since “/bin” directory has precedence over the “/tmp” one, and the second answer solves the problem (placing “/tmp” before the directory) since it forces “/tmp” to be read before the standard PATH. Conversely, the latter answer causes a security concern, since “/tmp” is publicly writable file by all users.

If it were to keep the program named “ls”, I can infer then that the problem would lie on the “/tmp” location where the newly created program “ls” has been placed. Allow me to kindly request you where, the new "ls" program should be placed (in which directory) to avoid the security problem that having it located on “/tmp” represents to find a solution.

Thanks in advance for your time and support.

Josep Maria

KevinCSmallwood

The simple answer is try not to name your commands after system commands if they have a different function. On the other hand, let's say you want to have your own "ls" command that lists the contents of directories (although I'll point out, if you read the manual page (i.e., "man ls"), you will find that the "ls" command has a lot of options and can do a lot of things that you may not be able to duplicate with your own program--don't reinvent the wheel), general convention says to put that in your "~/bin" directory. As I alluded, it would be better to call it something like "myls" and put it in your "~/bin" directory so that you don't have the name conflict. The convention "bin" stands for "binary" and is where you usually find executable programs (some may be compiled programs, and some may be executable shell scripts). You can create (if it doesn't already exist) and place your own executables in that "bin" directory. Let's go back to your other question about aliases. In this case, it would be better to call your "ls" executable something like "myls," put it in "~/bin/myls" (usually, but not always, "~/bin" may appear in your $PATH environment variable, but you know how to add it!), and if you really want "ls" to always execute your "myls" executable, then do this:

$ alias ls myls

As you now know, type "ls" at the command line prompt will then have the system execute the "myls" command. As long as that name is unique in the search path, it will find it and execute "myls". It is very common for some people to have aliases for various "ls" commands and options. For example:

$ alias lls   'ls -l'

That makes the "lls" command automatically execute an 'ls -l'. So, with this alias, you could do something like:

$ alias lls   'ls -l'
$ lls /usr       # NOTE that "ls -l" will be substituted for "lls" in this example!
<the result of an "ls -l /usr" will be shown>
$ 

Keep working through the course. I've been working with UNIX and then Linux since 1980 and still learn new things! As I like to say, you never stop learning until you die, and then, maybe you learn something new! ;-)

josepmaria

@KevinCSmallwood thank you for taking the time to provide this accurate answers. I really appreciate it. Thanks to your answers I now understand better many Linux concepts. I shall continue studying through the course.

KevinCSmallwood

You are most welcome, and I'm glad it was useful!