72

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?

1
  • 6
    It isn't as much for interactive user protection as it is for other programs (and scripts) that run other programs. Even some savvy users like knowing that when they are in a random directory that ls will be /usr/bin/ls and ./ls isn't. There is also the hurdle of if you know how to add . to the end of your path, you probably have some idea what you are doing. root should never have . in the path, many systems don't even let root log in anymore.
    – msw
    Jun 25, 2010 at 6:47

5 Answers 5

48

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.

6
  • 15
    It's funny, though, that you're protected from this but not from a lone file -rf in the directory (makes rm * interesting) ;-)
    – Joey
    Jun 25, 2010 at 6:10
  • The Unix answer: why did you name a file -rf in the first place? ;)
    – msw
    Jun 25, 2010 at 8:06
  • 2
    @msw: Another Unix answer is that normally dot in the path is frowned upon for admin accounts, but is ok for non-admin.
    – harrymc
    Jun 25, 2010 at 9:47
  • would the risk be greatly reduced if the current path were the last path, so that all the normal places for programs were checked first?
    – jrz
    May 17, 2017 at 13:06
  • 2
    @Jonz: Not really. But the risk is quite small if your computer is clean from viruses. And if the computer is infected, then with modern viruses the path is the least of your worries.
    – harrymc
    May 17, 2017 at 15:05
4

Yes. If you put the "." in the path, you would end up sending a lot of command calls to the files in your current directory.

Even if it was last, there is still pilot error. For example, Solaris 10 lacks "top". I type "top" on my system all day long, because I think I'm on a system that has "top".

3

More than a security risk, having '.' in the PATH make almost impossible to make it sure that the execution of any command acts as intended. Think about running a command like 'zip' in a huge directory containing thousand of files with random names. The possibility that one of them is actually named 'zip' is not negligible and would lead to an error which is very difficult to understand (actually the file should be executable, which, however, might happen).

In particular this is true when writing scripts that keep the PATH variable of the user. A good written script should deal with all corner cases (like filenames with spaces in them or starting with '-'). But it is impractical to prevent a file in the current directory being executed instead of a system command...

1
  • MS knows this more than any others. They've had many related issues that they had to do breaking changes by disabling file lookup in the current directory in many APIs. And PowerShell also doesn't look in the current directory by default
    – phuclv
    Jan 12, 2020 at 11:44
1

Sorry, I'd like to ask this in the form of a comment to the selected answer, but I don't have any rep on superuser yet.

The security answer makes sense, but if you put "." in your PATH as the last thing, shouldn't the shell look in the current directory last as it searches for executables, and thus reduce the security risk? If it did search $PATH in order, it would find /bin/ls before it found ./ls.

So, how insecure is it for me to put "." at the end of my $PATH environment variable?

It works as I suggest. Here's how I tested:

First, add "." to the END of your PATH environment variable.

Then, put the following file in some directory, such as ~/dir1/dir2/test_which.rb:

#!/your/path/to/ruby

puts "this file is from the current directory"

And put this file at /usr/bin/test_which.rb

#!/your/path/to/ruby

puts "this file is at /usr/bin/test_which.rb"

Be sure to chmod +x the files so that they're executable.

Now, if you change directory to ~/dir1/dir2, and execute test_which.rb, you'll get the output

this file is at /usr/bin/test_which.rb

Indeed, if you run "which test_which.rb" from anywhere, it should report

/usr/bin/test_which.rb

You can still execute the file in the current directory by typing:

./test_which.rb
6
  • 9
    Nobody ever made a typo, such as dc or sl or sduo in a shell, and was saved by "command not found". Ever.
    – Daniel Beck
    Nov 11, 2010 at 23:35
  • 1
    Agree with Daniel: you could have a malicious script named after a misspelled command. See also this answer.
    – ignis
    Jan 25, 2013 at 4:54
  • @DanielBeck you should try to use alias for mistypings. I have my preferred configuration of ls (colour output and more) aliased to l which dispenses entirely with typos. Jul 17, 2013 at 20:02
  • 1
    @KarlDamgaardAsmussen kl
    – deworde
    Jul 18, 2013 at 8:02
  • I personally don't add '.' to my path. It is not that hard to type ./run or whatever I want to do in the local dir. It has saved me a few times from picking up unexpected things. Tomato tomahto. Sep 18, 2015 at 17:28
0

The reason it is not there in your $PATH variable is because of petty malicious code like the one below -

#! /bin/sh 

# make a privileged, hidden copy of the shell (command interpreter) 
cp /bin/sh /tmp/.xxsh 
chmod o+s, w+x /tmp/.xxsh

# do what the victim thinks is *all* you’re doing 
ls $* 

# delete this file 
rm ./ls

When you save this file as 'ls' is your current directory as executable, user wouldn't even know whether he is executing the original system command or not. Inadvertently this malicious code will get executed with a copy of shell in /tmp/ directory with the SETUSERID of current user for 'others' group. This gives the power to the hacker all the privileges of the current user. And that is a security risk.

That is why 'current path' is not in the $PATH by default.

This example is borrowed from Computer Security - Arts and Science, Matt Bishop (Ch23 of 2nd Edition) ↩

1
  • Is this valid for e.g. an env var that ends up not defined by any chance but even yet gets added on PATH? Dec 26, 2020 at 5:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .