History of UNIX not including current directory in $PATH

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.)

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 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.

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0