Here is a question that I can't seem to find a good answer to.
Under Windows/DOS we have been "taught" that it is ok for use to be able to launch programs from the current directory without having to prefix the path.
However, the default behavior for Linux is that you must prefix ./ for applications/scripts in the current directory.
People say that it is a bad security practice to allow programs/scripts to execute without prefixing the directory. There a lot of "bad security practices", but this one doesn't make sense to me. For example, I am not going to enter /some/unfamiliar/directory and start executing programs like ls. I would cd (to get to my home directory), then type ls -la /some/unfamiliar/directory. Of course, on a bad day I would.
I can see the "threat" if someone puts a program with the name of ls in a directory, and a bad sysadmin cds to that directory and runs ls as root and the ls adds a backdoor user and other evil things. Fine. But, usually in that case a user would complain "oh ls isn't working can you check into that?". I would sudo su "user" and try ls as him.
Unless I am completely missing something, is adding "." to your PATH really that bad?
Edit:
All the answers so far are fine for pointing out the security risks – however – everyone is missing the arguments for Windows. Under Windows the current directory is NOT in your path, so there is no way to disable the ability to just run program.exe afaik. However, the command prompt does accept the ability to prefix the command with .\ (.\ does seem to work, however, you should use \ otherwise you could end up with an escape sequence of some kind). Under Windows should we always prefix the command? Also, should we contact Microsoft and tell them they are bad for implanting this expected behavior?
My background is Windows, so I am biased in expecting programs in the current directory to be able to run, even though I know that isn't the way it works in the Unix world. Which is why I presented the question out there.
To expand what I mean on "bad security practices" (and why they are in quotes) is because we could cite millions, if not billions, of security practices that people SHOULD be doing…but we don't and if we did, a person would certainly go insane. Should we mitigate every security risk with the potential of interfering with the user's experience? I say no but that is because I believe security should be transparent to the user(s), but I like haus's first sentence in his response "As much as anything else it is a mindset.". And I think we should leave it at that.
Best Answer
As much as anything else it is a mindset.
By having your current directory as part of your path you are indeed increasing your risk. Just because a trojan program has been executed, does not mean that it will not do what one would expect of it. In other words, to use your ls example, the trojan program, unless it was designed by a dunce would indeed provide you the directory listing that you requested, so that unless you say the file sitting there, you would have no reason to expect that something had gone wrong (perhaps it would be smart and decide to remove itself from the directory list provided to lower the chance of detection even further).
For this to occur, it would mean that someone has already infiltrated a given system to the point that it could place files onto your file system. Thus you are already in a bad way, but there is still room for things to be made worse.
As a general practice, I do not place my current directory in my path on my linux/unix systems, and it is not a great hardship. When I write a program or script that I wish to use frequently, I place it into a folder that is in my path, and restrict the write permissions to said file.
Short answerer, will adding the current directory to your path lead to certain doom for a unprivileged user, likely no, but why take the chance?
For root, DO NOT DO IT.