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