Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
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?
If you're the only user on the machine it's okay, as long as you know what 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 a script/program from your current directory, you can always explicitly run it by prepending ./ to its name (you telling the system "I want to run this file from my current directory").
Say, now you have all these 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 appending it to the end of the 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 unintentionally run a malicious script there only because you mistyped a thing or script that has the same name as a system-wide binary.
ls in your current directory. next you run ls to inspect the extracted files and you have already run the malicious code.
. at the end of PATH though, could it?
Oct 18, 2021 at 4:23
sl or lss for example in the current directory, and if you mistype ls as one of those options then it will execute that malicious code
The risk is someone put a malicious executable in the directory that happen to be your current one.
The worst case happen when:
. 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:
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 malicious or compromised site.
ls to get a directory listing but some project I download might have a ls script in their root project folder as a shortcut to something else. ls is probably a bad example but I can certainly imagine e for edit, d for debug, m for make, b for build. I have some of those myself globally. If I type m I expect make to launch (my shortcut), not some local script called m to execute.
w and [.
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.
