47

I've seen people mention in other answers that it's a bad idea to include the current working directory ('.') in your $PATH environment variable, but haven't been able to find a question specifically addressing the issue.

So, why shouldn't I add . to my path? And if despite all warnings I do it anyway, what do I have to watch out for? Is it safer to add it to the end than to the the start?

37

If you're the only user on the machine it's OK, as long as you know what's you're doing. The general concern is that by having your current directory in PATH, you cannot see commands as a constant list. If you need to run script/program from your current directory, you can always explicitly run it by prepending ./ to its name (you saying the system "I want to run this file from my current directory").

Say, now you have all this little scripts all over your filesystem; one day you'll run the wrong one for sure. So, having your PATH as a predefined list of static paths is all about order and saving oneself from a potential problem.

However, if you're going to add . to your PATH, I suggest you to append it to the end of list (export PATH=$PATH:.). At least you won't override system-wide binaries this way.

If you're a root on the system and have system exposed to other users' accounts, having . in PATH is a huge security risk: you can cd to some user's directory, and non-intentionally run malicious script there only because you mistyped a thing or script has the same name as a system-wide binary.

  • 1
    +Accept for the underlying theory and for mentioning that the problems can still exist even when you're the only user on the system. Both answers bring up excellent points. I'll add that any time you share directories with another user, there is increased risk, whether you're root or not. – Jander Feb 25 '13 at 14:48
  • 5
    even as the only user on the machine: everytime you extract an untrusted tar it can place an ls in your current directory. next you run ls to inspect the extracted files and you have already run the malicious code. – lesmana Feb 10 '17 at 8:26
35

The risk is someone put a malicious executable in the directory that happen to be your current one.

The worst case happen when:

  • you are logged as root as the malicious command has unlimited damage power
  • . is at the beginning of your PATH as standard commands can be overridden without you noticing it (typically an ls which could hide itself from the list).

The risk is much lower if you are logged as a regular user and have the . at the end of your PATH but it still exists:

  • someone might find out you frequently mistype a command and install a matching one
  • someone might install a fake command with the name of one that is not installed.

Note that in any case, the risk is still there even if you are the only user of the machine. Malicious software would be installed if, for example, you happen to extract an archive downloaded from a compromised site.

  • 15
    Install sl to see how often point 3 happens. – jordanm Feb 22 '13 at 6:19
  • or alias l=`ls`. – Anko Mar 31 '14 at 11:15
3

Even if you are always very careful with what you type, putting . to your PATH, even at the end, is still insecure because some programs change the current directory to /tmp (which is world writable) and may also try execute utilities that are actually not installed, thus defaulting to what is in /tmp. If this occurs, this is a vector of attack.

Note also that there isn't much drawback of avoiding . in PATH, because ./ is easy to type (in particular on keyboards like QWERTY, where these characters are on consecutive keys and do not need Shift) and using ./ will also help completion, thus potentially saving keystrokes at the end.

If you really want to be able to type commands from the current directory, then modern shells (like zsh, with its command_not_found_handler) may provide features to do that safely, i.e. allowing you to add all the security checks you want in the handler, before the command is executed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.