5 ms·

What's wrong with having '.' in your $PATH?

tfh 16y ago
I never considered having "." in my $PATH because typing "./" is very convenient in the us keyboard layout.
- yason 16y ago
  Slightly off-topic but it seems to me that most keyboard layouts but the US seem to be completely retarded—almost bordering a conspiracy—with regard to usability when coding, using emacs and using the unix shell. When I see someone coding with a non-us layout I smell the humble inexperience and nod with compassion. The difference between layouts can be astonishing if you only bang a lots of []{}|/\?-=+_-*()@#$'s. For some reason, computer languages are full of those. I use the us layout all the time except when I have to write something in my native language and need the umlauts more easily. I remember the killing pain of trying to write code in it until I realized I can just turn on the US keyboard. Luckily, that was before my career...
  - xorglorb 16y ago
    Actually QWERTY was created to slow typists down. Back in ye olde days, when typewriters were still around, there was the problem where people who typed to fast would jam the typewriters. Thus, QWERTY was invented to slow people down so the typewriters wouldn't jam. Then, when computers came along, everybody knew QWERTY, so they continued using it.
    - stephencelis 16y ago
      That's an apocryphal story, though. QWERTY was said to have been invented, actually, to make it easier for typewriter salesmen to type "TYPEWRITER", all from the top row.
- ludwigvan 16y ago
  Actually that's (and typing other frequent programming related stuff like the semicolon, or the brackets) one of the reasons I switched to us keyboard layout.
paulitex 16y ago
This is more of a tip than a warning. This answer was clearly written when *nix systems were largely multi-user systems. The security reasoning doesn't hold at all on personal computers - in fact I'm going to add "." to my PATH for sure now, hadn't ever considered it. (I'm pretty sure I don't leave malicious executables "lying around" my mac, and if I somehow did that'd be my own dumb fault).
- cdavid 16y ago
  While the security issues does not seem as high in "modern" environments (mostly single user systems), I think it is still a significant risk because of the surprise factor. For example, on my mac, there are > 2000 binaries available in my PATH. I cannot possibly know all of them, and if one binary uses another underlying binary I don't know about, it can be quite surprising. I don't think it worths it (using ./ + tab for completion is faster than typing the name of the binary anyway)
- vog 16y ago
  To be more concrete, imagine another user places a malicious script into the file "/tmp/ls". If later someone else wants to look what temporary files are there, typing "cd /tmp" and then "ls", that person would suddenly execute the malicious script without even noticing. This is even worse if that happens to root, which is why this advice is especially important for the root user. Also, note that for often-used self compiled binaries, $HOME/bin is a good place. On some systems, $HOME/bin is already added to the user's PATH by default, so you just have to create that directory and put your favorite binaries or shell scripts into that.
- caf 16y ago
  Do you occaisionally untar archives created by other people? Such archives can also contain executable files.
- ssp 16y ago
  A lot of the classic Unix security advice is pretty outdated. For example the idea that someone getting "root" access is worse than someone gaining "ssp" access. Everything interesting is already readable and writable by ssp. The only new thing root can do is destroy stuff that can pretty easily be recreated. The root account is still useful to prevent ssp from accidentally screwing things up, but as a security measure it's pointless in many cases.
sendos 16y ago
This isn't 100% secure though - if you're a clumsy typist and some day type "sl -l" instead of "ls -l", you run the risk of running "./sl" If you're a clumsy typist, even if you don't have '.' in your $PATH, you might still type ./sl (instead of your intended ./ls) and get the "rogue" program to run. I've had . in my $PATH for the last couple of decades. It's fine.
- burgerbrain 16y ago
  1) that's a far less likely scenario 2) you shouldn't be running programs out of publicly writeable directories on hostile multiuser systems anyway. 3) (not directly related to your post) explicitly using ./ allows for more accurate completions, almost always making up for the two extra characters typed (particularly since ./ is so easy to type with a single motion).
- goodside 16y ago
  The point is that you would never tpye "./ls" when you meant to type "ls". Or at least I wouldn't. I just grepped through (several years of) my bash logs and I have never once in my life typed "./ls", accidentally or otherwise. I consider this strong evidence.
DrStalker 16y ago
I avoid adding '.' to my path because I work on a lot of different linux and unix systems as part of my job, and having a consistent command line I can use without having to remember where I am and how I set things up is more productive for me than saving a bit of time on my personal system. For the same reason I don't use a custom .vimrc file; it's great when on a configured system but causes problems elsewhere.
- nitrogen 16y ago
  For years I held a similar philosophy, then I decided, "Screw it, I can just copy .vimrc and .bashrc to whatever system I need, and if that's not possible, I can adapt to the defaults." I haven't done too much customization yet, but after seeing some example .vimrc and .bashrc files online, there's a lot of potential for improving productivity.
  - goodside 16y ago
    Even better, keep them in a GitHub repository and include an installation script. All the comforts of home in a carpet bag.
bluesmoon 16y ago
Having . in your $PATH isn't a major security issue on its own. I'd classify it at S3. The problem with S3s though, is that two separate S3s can combine to create an S1 or an S0, which can bite you. If you've had . in your PATH for a long time and never had a problem with it, it's either because there isn't anything else open that makes this an issue (fairly likely), or that no one's really bothered to exploit your system (also fairly likely)
ludwigvan 16y ago
I had tried this, and had makefiles fail because of this. It seems that if you insist on saving $PATH this way, you should NOT to `export` it.
hackermom 16y ago
I'm really surprised over the complete lack of thought shown by people who spend time writing about this. The problem isn't really about having . in your path, but the old mistake of having it AS THE FIRST THING in your path, before your shell has a chance to reach its usual important locations (/bin, /sbin, /usr/bin, /usr/local/bin and so forth). Put it as the last thing in your path variable and you won't be having any problems worth mentioning (hey, even the OpenBSD guys finally went with this solution after having banished . entirely for years).
- deleted 16y ago
  [deleted]
- tzs 16y ago
  What about those of us who aren't 100% perfect in our spelling and/or typing of command names?
antfarm 16y ago
Makes me think: the exploit he describes is the UNIX-predecessor of today's web's XSS attacks ...
broofa 16y ago
'Have had "." in my $PATH for 20 years. It's never been a problem... and probably saved me several hundred thousand keystrokes. Having to worry about there being an "ls" in the current dir is about the same as worrying whether or not there are multiple versions of _any_ binary elsewhere in $PATH. This is a non-issue.
- qwzybug 16y ago
  wget http://some.dudes.site/cool_stuff.tar untar cool_stuff.tar cd cool_stuff ls Oh but whoopsy-doodle, cool_stuff comes with this extra-cool script: cat ./ls #!/usr/bin/my-favorite-scripting-language do_sneaky_things :with => AllOfYourStuff && `rm -rf /`
  - stephencelis 16y ago
    If you're diligent to ls cool_stuff before changing directories, it's less of an issue. And `rm -fr /' is less likely than `rm -fr ~', since most people don't need root access to call `ls'. But still, I don't add '.' to my path because the only time I directly reference files in my current directory, it's because of a Zsh suffix alias.
daxelrod 16y ago
Fun corollary to this, having an empty element in your $PATH (for example, "/foo::/bar") is the same as having '.' in your $PATH, at least under bash. This will usually happen when a login script puts the value of a variable in your $PATH without actually checking whether that variable has any contents.

tfh 16y ago

I never considered having "." in my $PATH because typing "./" is very convenient in the us keyboard layout.

yason 16y ago
Slightly off-topic but it seems to me that most keyboard layouts but the US seem to be completely retarded—almost bordering a conspiracy—with regard to usability when coding, using emacs and using the unix shell. When I see someone coding with a non-us layout I smell the humble inexperience and nod with compassion. The difference between layouts can be astonishing if you only bang a lots of []{}|/\?-=+_-*()@#$'s. For some reason, computer languages are full of those. I use the us layout all the time except when I have to write something in my native language and need the umlauts more easily. I remember the killing pain of trying to write code in it until I realized I can just turn on the US keyboard. Luckily, that was before my career...
- xorglorb 16y ago
  Actually QWERTY was created to slow typists down. Back in ye olde days, when typewriters were still around, there was the problem where people who typed to fast would jam the typewriters. Thus, QWERTY was invented to slow people down so the typewriters wouldn't jam. Then, when computers came along, everybody knew QWERTY, so they continued using it.
  - stephencelis 16y ago
    That's an apocryphal story, though. QWERTY was said to have been invented, actually, to make it easier for typewriter salesmen to type "TYPEWRITER", all from the top row.
ludwigvan 16y ago
Actually that's (and typing other frequent programming related stuff like the semicolon, or the brackets) one of the reasons I switched to us keyboard layout.

This is more of a tip than a warning. This answer was clearly written when *nix systems were largely multi-user systems. The security reasoning doesn't hold at all on personal computers - in fact I'm going to add "." to my PATH for sure now, hadn't ever considered it. (I'm pretty sure I don't leave malicious executables "lying around" my mac, and if I somehow did that'd be my own dumb fault).

cdavid 16y ago
While the security issues does not seem as high in "modern" environments (mostly single user systems), I think it is still a significant risk because of the surprise factor. For example, on my mac, there are > 2000 binaries available in my PATH. I cannot possibly know all of them, and if one binary uses another underlying binary I don't know about, it can be quite surprising. I don't think it worths it (using ./ + tab for completion is faster than typing the name of the binary anyway)
vog 16y ago
To be more concrete, imagine another user places a malicious script into the file "/tmp/ls". If later someone else wants to look what temporary files are there, typing "cd /tmp" and then "ls", that person would suddenly execute the malicious script without even noticing. This is even worse if that happens to root, which is why this advice is especially important for the root user. Also, note that for often-used self compiled binaries, $HOME/bin is a good place. On some systems, $HOME/bin is already added to the user's PATH by default, so you just have to create that directory and put your favorite binaries or shell scripts into that.
caf 16y ago
Do you occaisionally untar archives created by other people? Such archives can also contain executable files.
ssp 16y ago
A lot of the classic Unix security advice is pretty outdated. For example the idea that someone getting "root" access is worse than someone gaining "ssp" access. Everything interesting is already readable and writable by ssp. The only new thing root can do is destroy stuff that can pretty easily be recreated. The root account is still useful to prevent ssp from accidentally screwing things up, but as a security measure it's pointless in many cases.

sendos 16y ago

This isn't 100% secure though - if you're a clumsy typist and some day type "sl -l" instead of "ls -l", you run the risk of running "./sl" If you're a clumsy typist, even if you don't have '.' in your $PATH, you might still type ./sl (instead of your intended ./ls) and get the "rogue" program to run. I've had . in my $PATH for the last couple of decades. It's fine.

burgerbrain 16y ago
1) that's a far less likely scenario 2) you shouldn't be running programs out of publicly writeable directories on hostile multiuser systems anyway. 3) (not directly related to your post) explicitly using ./ allows for more accurate completions, almost always making up for the two extra characters typed (particularly since ./ is so easy to type with a single motion).
goodside 16y ago
The point is that you would never tpye "./ls" when you meant to type "ls". Or at least I wouldn't. I just grepped through (several years of) my bash logs and I have never once in my life typed "./ls", accidentally or otherwise. I consider this strong evidence.

DrStalker 16y ago

I avoid adding '.' to my path because I work on a lot of different linux and unix systems as part of my job, and having a consistent command line I can use without having to remember where I am and how I set things up is more productive for me than saving a bit of time on my personal system. For the same reason I don't use a custom .vimrc file; it's great when on a configured system but causes problems elsewhere.

nitrogen 16y ago
For years I held a similar philosophy, then I decided, "Screw it, I can just copy .vimrc and .bashrc to whatever system I need, and if that's not possible, I can adapt to the defaults." I haven't done too much customization yet, but after seeing some example .vimrc and .bashrc files online, there's a lot of potential for improving productivity.
- goodside 16y ago
  Even better, keep them in a GitHub repository and include an installation script. All the comforts of home in a carpet bag.

bluesmoon 16y ago

Having . in your $PATH isn't a major security issue on its own. I'd classify it at S3. The problem with S3s though, is that two separate S3s can combine to create an S1 or an S0, which can bite you. If you've had . in your PATH for a long time and never had a problem with it, it's either because there isn't anything else open that makes this an issue (fairly likely), or that no one's really bothered to exploit your system (also fairly likely)

ludwigvan 16y ago

I had tried this, and had makefiles fail because of this. It seems that if you insist on saving $PATH this way, you should NOT to `export` it.

hackermom 16y ago

I'm really surprised over the complete lack of thought shown by people who spend time writing about this. The problem isn't really about having . in your path, but the old mistake of having it AS THE FIRST THING in your path, before your shell has a chance to reach its usual important locations (/bin, /sbin, /usr/bin, /usr/local/bin and so forth). Put it as the last thing in your path variable and you won't be having any problems worth mentioning (hey, even the OpenBSD guys finally went with this solution after having banished . entirely for years).

deleted 16y ago
[deleted]
tzs 16y ago
What about those of us who aren't 100% perfect in our spelling and/or typing of command names?

antfarm 16y ago

Makes me think: the exploit he describes is the UNIX-predecessor of today's web's XSS attacks ...

broofa 16y ago

'Have had "." in my $PATH for 20 years. It's never been a problem... and probably saved me several hundred thousand keystrokes. Having to worry about there being an "ls" in the current dir is about the same as worrying whether or not there are multiple versions of _any_ binary elsewhere in $PATH. This is a non-issue.

qwzybug 16y ago
wget http://some.dudes.site/cool_stuff.tar untar cool_stuff.tar cd cool_stuff ls Oh but whoopsy-doodle, cool_stuff comes with this extra-cool script: cat ./ls #!/usr/bin/my-favorite-scripting-language do_sneaky_things :with => AllOfYourStuff && `rm -rf /`
- stephencelis 16y ago
  If you're diligent to ls cool_stuff before changing directories, it's less of an issue. And `rm -fr /' is less likely than `rm -fr ~', since most people don't need root access to call `ls'. But still, I don't add '.' to my path because the only time I directly reference files in my current directory, it's because of a Zsh suffix alias.

daxelrod 16y ago

Fun corollary to this, having an empty element in your $PATH (for example, "/foo::/bar") is the same as having '.' in your $PATH, at least under bash. This will usually happen when a login script puts the value of a variable in your $PATH without actually checking whether that variable has any contents.