History of UNIX not including current directory in $PATH

Question

In the UNIX world, it's well understood that you need to prefix binaries in the current directory with ./ in order to run them: . is not in $PATH by default. This is to avoid evil binaries overriding system utils like ls and getting code exec.

I would like to know the history of this decision. Was it in UNIX from the beginning? Certain shells?

I want to be clear: I'm not looking for reasons in general why it was implemented; I understand those. I'm looking for the event that caused it or at least when the change was made.

Citations would be much appreciated.

Interestingly, it looks like bash actually intends to include ., at least that's my reading of this source (from config-top.h):

/* The default value of the PATH variable. */
#ifndef DEFAULT_PATH_VALUE
#define DEFAULT_PATH_VALUE \
  "/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:."
#endif

(Some have questioned the relevance of this question. There's been some talk about a number of executable installers on Windows that are vulnerable to a similar attack: executables by default will search for DLLs in ., so by planting an evil DLL in say Downloads, you get code exec, often as admin. It's a "Those who don't learn history are doomed to repeat it" moment.)

Answer 1

It will be no easy task to find "historic documents" about this decision, but quoting another answer from the StackExchange umbrella, you will find what I also think is the most appropriate answer to your question: to avoid "sh## happens" scenario:

• bash: Why is . not in the path by default?

Question:

On UNIX-like systems over the years (most relevantly to me, Linux), I've noticed that . (current dir) is never in the $PATH by default. Why is this? I recall reading years ago that it was a security problem, but the article I read didn't explain what exactly the problem was. Is it because someone could leave a malicious version of 'ls' or 'cp' in a directory, and I'd end up running it without realizing it was there?

Answer:

You answered correctly your own question, that's exactly why dot isn't in the path: To protect against childish viruses or honest mistakes.

Of course, this is a very lame and useless anti-virus measure, and nothing stops you from adding dot to the path yourself.

And on this link, you can find an additional example why is dangerous to put the dot on your $PATH.

Footnote:

An extreme example would be the situation in which an ordinary user created a shell script such as rm -r /, which would delete all files and directories in the system for which the user had writing permission, and named this script ls. Were the system administrator to navigate to the directory in which this script was located and attempt to run the standard ls command in order to view the contents of that directory, the shell would instead run the script with the same name and thereby remove the contents of all currently mounted partitions on the computer!

Also, the purpose of PATH is to complete the path of a command in such way you don't need to remember or type the full path of your binaries. There is no need to index commands of a directory you are in. It's not useful at all if you know where these programs are stored.

EDIT:

However, after some research, I found that the idea behind the search path came from Multics, but the limitation was that it only searched inside /bin. Unix v3 was the first to implement it without this one-directory limitation. And taking a look at the security pages of the following manual, they already have shown what are the issues while using . in a PATH variable. This applies not only to su and it reinforces the security matter of injecting malicious code on the environment.

• A Research Unix reader: annotated excerpts from the Programmer's Manual, 1971–1986

Quoting page 13:

Trojan Horse tricks and countermeasures were discovered in an ongoing game that has been recounted by Morris and Fred Grampp. Notice, for example, the removal of login(1) to chapter 8 and the intrusion of /etc/ into the synopsis for su (Grampp, v8). These fillips defeated the old chestnut of leaving programs named login or su lying around in hopes of capturing a password typed by an unwary system administrator. Other subtle features of the modern su: dot is excluded from the shell search path and the burglars’ favorite shell variable IFS is reset.

Since its conception, this feature has proved dangerous if using dot as part of the $PATH.